Hey Matthias,

Further to previous emails, I've also tried forcing 

Simulator set WirelessNewTrace_ 1 

in ns-default.tcl

It's definitely being set (debug line), but the output log is still in
old format.

So, I suppose the problem must be somewhere in the nsclick stuff? It's
either resetting the flag, or just not honouring it somewhere.... 

Again, any thoughts would be very much appreciated,

Best Regards,

Dave

-----Original Message-----
From: Matthias Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: 26 February 2007 13:27
To: David Bath
Subject: Re: [ns] new wireless trace format

OK,
 the calling for this function for the "common" mobile node runs through
the ns-lib.tcl and ns-mobilenode.tcl.
First with the use-newtrace the variable WirelessNewTrace_ is set to 1,
and within the creation of the mobile node the newtrace is set to the
value of the WirelessNewTrace_. One thing that relates to that is, that
before anything of the mobilenode is set or the node is created the call
to $ns_ use-newtrace must be done...
otherwise the default value of 0 is taken...
You should have a look at the tcl part of the creation of the click node
and perhaps compare it to the mobilenode. 


Matthias


-------- Original-Nachricht --------
Datum: Mon, 26 Feb 2007 12:45:50 -0000
Von: "David Bath" <[EMAIL PROTECTED]>
An: ns-users@ISI.EDU
CC: 
Betreff: Re: [ns] new wireless trace format

> 
> 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
> >>
> >>
> >
> >
> >
> 
> 

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

Reply via email to