Re: [ns] new wireless trace format
Hi list, Try as I might, I can't get my wireless traces to spit out in new format. I'm using nsclick (compiled with ns2 version 2.3) and it seems to otherwise be performing fine. However, when I try the well-documented: set ns_ [new Simulator] set tracefd [open filename w] $ns_ use-newtrace $ns_ trace-all $tracefd The output resolutely comes out in old format. I've also tried setting: Simulator set WirelessNewTrace_ 1 (as seems to be in the ns-lib.tcl) And Simulator set newTraceFormat_ 1 (as seems to be indicated in http://www.isi.edu/nsnam/ns/doc/node185.html) But no joy. Any suggestions would be very welcome. Best Regards, Dave Bath University of Bristol, UK
Re: [ns] new wireless trace format
Hi List, A small update on this. I've been working today to try and find a more precise set of conditions. It seems I can't produce a new trace format if I use the a mobile node of type Click. As suggested in the nsclick papers, I am using Simulator set node_factory_ Node/MobileNode/ClickNode As soon as I do that, the use-newtrace directive appears to be being ignored. I can't really find out a sensible combination of options to get more precise than this - purely that something about using a ClickNode prohibits traces in the new format. Any thoughts very gratefully received! Best Regards, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Bath Sent: 25 February 2007 00:02 To: ns-users@ISI.EDU Subject: Re: [ns] new wireless trace format Hi list, Try as I might, I can't get my wireless traces to spit out in new format. I'm using nsclick (compiled with ns2 version 2.3) and it seems to otherwise be performing fine. However, when I try the well-documented: set ns_ [new Simulator] set tracefd [open filename w] $ns_ use-newtrace $ns_ trace-all $tracefd The output resolutely comes out in old format. I've also tried setting: Simulator set WirelessNewTrace_ 1 (as seems to be in the ns-lib.tcl) And Simulator set newTraceFormat_ 1 (as seems to be indicated in http://www.isi.edu/nsnam/ns/doc/node185.html) But no joy. Any suggestions would be very welcome. Best Regards, Dave Bath University of Bristol, UK
Re: [ns] new wireless trace format
Hi Shaili, Thanks for reply. However, as you can see from my original post, I have tried that command. It does not produce the results as expected. Indeed, if you read my updated post, you will see that it only seems to not work when I'm using Click mobilenodes. Under this condition it seems to be ignored. Any other thoughts would be much appreciated! Best Regards, Dave From: Shaili Desai [mailto:[EMAIL PROTECTED] Sent: 26 February 2007 05:55 To: David Bath Subject: Re: [ns] new wireless trace format You need the command $ns_ use-newtrace and that will get you new format. Hope this helps! On 2/24/07, David Bath [EMAIL PROTECTED] wrote: Hi list, Try as I might, I can't get my wireless traces to spit out in new format. I'm using nsclick (compiled with ns2 version 2.3) and it seems to otherwise be performing fine. However, when I try the well-documented: set ns_ [new Simulator] set tracefd [open filename w] $ns_ use-newtrace $ns_ trace-all $tracefd The output resolutely comes out in old format. I've also tried setting: Simulator set WirelessNewTrace_ 1 (as seems to be in the ns-lib.tcl) And Simulator set newTraceFormat_ 1 (as seems to be indicated in http://www.isi.edu/nsnam/ns/doc/node185.html) But no joy. Any suggestions would be very welcome. Best Regards, Dave Bath University of Bristol, UK -- Thanx Shaili Desai Master's Candidate Telecommunications and Management University of Maryland,College Park,USA
Re: [ns] new wireless trace format
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 -Original Message- From: ?e Olbert [mailto:[EMAIL PROTECTED] Sent: 26 February 2007 08:41 To: David Bath Subject: Re: [ns] new wireless trace format Have you checked that there is support form the Click node to print in the new format? And have you checked in cmu-trace.cc if it is able to print other than the basic node format?
Re: [ns] new wireless trace format
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
Re: [ns] new wireless trace format
Hi Matthias,
Thanks very much for the reply.
I had a look in ns-lib.tcl, and found that use-newtrace sets the
variable:
Simulator set WirelessNewTrace_ 1
I've tried setting this manually, but it makes no difference.
Just to reiterate - either versions works when straight ns is used,
but neither work when a ClickNode is used.
Sorry if I misunderstood...
Best Regards,
Dave
-Original Message-
From: Matthias Kuhnert [mailto:[EMAIL PROTECTED]
Sent: 26 February 2007 10:07
To: David Bath
Subject: Re: [ns] new wireless trace format
The newtrace variable is set via the tcl interface - grep for the
appropriate command function, if you are interested in the exact
location...
There should be also some default setting within the ns-default.tcl.
But if you are curious on how the system reacts, just set the newtrace
variable to 1 somewhere in the file, or within the ns-default,
recompile, and look what happens
Greets,
Matthias
Original-Nachricht
Datum: Mon, 26 Feb 2007 09:19:53 -
Von: David Bath [EMAIL PROTECTED]
An: ns-users@ISI.EDU
CC:
Betreff: Re: [ns] new wireless trace format
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
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
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
Re: [ns] new wireless trace format
For info: when I run the nsclick scripts, argv[1] is always equal to
namattach or target if this helps.
Cheers,
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
Re: [ns] new wireless trace format
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 -
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
Re: [ns] new wireless trace format
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 -
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
Re: [ns] new wireless trace format
Perfect.
In CMUTrace::CMUTrace(const char *s, char t) : Trace(t) {
Changed newtrace_ = 0 to newtrace_ = 1
}
And it seems fine - and reporting correct positions in the trace (at
least in my very first quick tests).
Thanks for the help!
Best Regards,
Dave
-Original Message-
From: Matthias Kuhnert [mailto:[EMAIL PROTECTED]
Sent: 26 February 2007 17:25
To: David Bath
Subject: Re: [ns] new wireless trace format
If you really want to try the new trace,
forget all the testing and searching in the tcl direction -
simply comment out the setting of the newtrace within the cmu-trace.cc
and put at the initialisation an 1 instead of the 0!
Or if that is not working - the next step would be forcing it by
replacing every newtrace within the cmu-trace.cc by an 1 :)
But remember, where you put them to undo the changes, if something went
wrong:)
Then recompile and run
Greets,
Matthias
Original-Nachricht
Datum: Mon, 26 Feb 2007 16:54:54 -
Von: David Bath [EMAIL PROTECTED]
An: ns-users@ISI.EDU
CC:
Betreff: Re: [ns] new wireless trace format
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 -
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
[ns] nsclick + tracefile strangeness
Hey list, I was hoping someone might give me a few pointers on this. I've got two Agents attached to sources (as far as I can see in a pretty similar manner to the nsclick example paper), as follows: Agent/Null set sport_ 5000 Agent/Null set dport_ 5000 Agent/CBR set sport_5000 Agent/CBR set dport_5000 set source_startxmittime 1 set source_xmitrate 400 set source_xmitinterval 0.1 set source_packetsize 64 set raw_(0) [new Agent/Raw] set null_(0)[new Agent/Null] $ns_ attach-agent $node_(0) $raw_(0) $ns_ attach-agent $node_(3) $null_(0) # Set up a raw channel between node0 and node3 $raw_(0) set-srcip [$node_(0) getip eth0] $raw_(0) set-srcport 5000 $raw_(0) set-destip [$node_(3) getip eth0] $raw_(0) set-destport 5000 $raw_(0) set fid_ 1 # Set up a CBR and attach it to the RAW set cbr_(0) [new Application/Traffic/CBR] $cbr_(0) set packetSize_ $source_packetsize $cbr_(0) set interval_ $source_xmitinterval $cbr_(0) set random_ 0 $cbr_(0) set maxpkts_ [expr ( $sim(stoptime) - $source_startxmittime ) * $source_xmitrate] $cbr_(0) attach-agent $raw_(0) $ns_ at $source_startxmittime $cbr_(0) start However, I'm a bit confused about what I'm seeing in my trace file. Essentially, I'm certainly not seeing pairs of AGT send and receive as I would expect. In fact, the first thing I see is a receive on node3 - but before there are any AGT sends! I'm using the simple flat arp-querier click definition, and I can happily see each packet (on port 5000) being sent tokernel and received fromkernel. I just seem to be having some difficulty accounting it in ns. If anyone has had any experience in this, I'd be most grateful for some insight. Best Regards, Dave Bath University of Bristol
