Hey Matthias (et al),
Many thanks for reply, much appreciated. $ns_ use-newtrace is done very
early in my tcl script, and it seems to work assuming I don't use a
clicknode.
Something is going a little bit wrong with node-config I think...
ns-clicknode.tcl is a subclass of ns-mobilenode.tcl (now, I'm not hugely
familiar with how tcl classes work), but I would think that means the
functions defined in MobileNode are available to click nodes...
However, the Node/MobileNode instproc mobility-trace ... { ... }
function never seems to be called, and that seems to be the place where
all the newtrace action happens...
Any thoughts on whether I'm reading this right?
Best,
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
