[ns] Traces and info
Hi all, - I want to know that I can find the threshold of the packet by inspecting the txinfo_.RxPr, which will wtell you if the packet is below the Rxthreshold and needs to be dropped. Now is there a way I can trace that in a trace file? Is there an exsiting functionality for this? -If there is a debug method in the Java code, how can I make it go to the file rather than to the my consol? - Is there a good tutorial you know about traces? I am having hard time understanding how to enable the Mac 802.11 traces as I see there is code alreayd written for these traces? Please help me in any of the questions as I got confused figuring it all out. The manual was not enough :(
[ns] wireless execution
hi, all can any body tell how to execute wireless programs in NS2, i am getting errors like command not found. is their any path set up please help me... Narendra
[ns] [NS-ANS] Re: How do I calculate the node utilization?
Hi Ahmed, In NS2, things happen very briefly in node. If you are working in a wired network, things happens in Simple link. For example, the queue is not associated with nodes (as in the physical world), but with the link. So you can't really find the utilization of the node. But if you are interested in finding link utilization. You may find it from link throughput / link capacity. I blogged a series on how to post-process NS2 result. You can find link utilization computation example from the link below: http://www.ns2ultimate.com/post/3442965938 Best Wishes, Teerawat Issariyakul http://www.ns2ultimate.com/ http://www.facebook.com/pages/Teerawat-Issariyakul/358240861417 http://twitter.com/T_Bear http://www.t-issariyakul.blogspot.com http://www.ece.ubc.ca/~teerawat On Feb 22, 2011, at 10:13 AM, Ahmad wrote: > > Hi all, > Trying one more time just incase. Anyone can suggest a way (through code or > analyzing trace files) that I can find the utilization of a node? I am trying > to > prove that a specific node is utilized more due to more packet, and extra > overhead processing.. > > thoughts? > Thank you > > > >
[ns] Perl Script for Comparing Energy Usage between Protocols
Is there any standard Perl Script to compare energy usage for nodes between protocols? Please help me out with this one or a guidance to how one can be created. Thanks in advance
Re: [ns] interference model
Hello Erico,
Generally speaking, the packet flow is: when a packet is sent by the
particular node from the network layer (down direction), it is first
received by the 802_11::recv. In the 802_11::recv, the direction of the
particular packet is checked, if it is down direction, the 802_11::send is
called. If the packet is up direction (means that the packet is received
from the phy layer), several conditions are checked including the including
the state of the channel and incoming power.
Note that 802_11::recv (packet direction up) is called by all the nodes
[i.e. packet is received by all the nodes] that are within the carrier
sensing range i.e. approx. 2 times the transmission range and then in the
packet, the error() bit is marked as 1 for those nodes that are outside the
transmission range of the node and has some errors or noise. [In previous
versions of ns2, the ch->error() bit is marked at the mac layer, but now it
is moved to physical layer ]. See ch->error(). Note that the ch->error() is
used to include the noise, bit erros: see wireless-phy.cc file,
WirelessPhy::sendUp(Packet *p) function. Moreover, in the same file, you can
see the modulation, FECs etc
Regards
Mubashir Husain Rehmani
Lip6/UPMC, Paris, France
On 22 February 2011 19:09, Érico Porto wrote:
> I understood these parameters, but the problem is, when a msg is sent, and
> we have a packet, the 802_11::recv will be called by which nodes?
>
> And why the wireless channel nodes in range when a msg is sent get delay
> time increased by a factor distance/speed of light, and why this happens
> inside a square?
>
> Also I'm not seeing any reference to noise, so it seems that it is not even
> a AWGN channel.
>
> Érico V. Porto
>
>
>
> On Tue, Feb 22, 2011 at 2:39 PM, Mubashir Rehmani wrote:
>
>> Please look at this also written by Kimaya on ns2 old mailing list:
>>
>> RXThresh_ is the reception threshold. If the received signal strength is
>> greater than this threshold, the packet can be successfully received.
>>
>>
>>
>> CSThresh_ is the carrier sensing threshold. If received signal strength is
>>
>> greater than this threshold, the packet transmission can be
>> sensed. However, the packet cannot be decoded unless signal strength is
>>
>>
>>
>> greater than RXThresh_.
>>
>> CPThresh_ refers to the capture phenomenon. If two packets are received
>>
>> simultaneously, i.e. they collide, it is still possible to receive the
>> 'stronger' packet if its signal strength is CPThresh_ times the other
>>
>>
>>
>> packet. For example, if CPThresh_ is 10.0, the stronger packet in a
>>
>> collision can be decoded if its signal strength is at least 10.0 times
>> that of the other packet; otherwise, both packets are lost in the
>> collision.
>>
>>
>>
>> Hope that helps.
>>
>> Kimaya
>>
>>
>>
>> On 22 February 2011 18:33, Mubashir Rehmani wrote:
>>
>>> Hello Erico,
>>>
>>> Here are some dicussions regarding RXThresh_ that may help you
>>> http://overegoz.tistory.com/668
>>>
>>> http://www.lastking.net/54?TSSESSIONlastkingnet=5ec6c07a691774bd721516037eafa42b
>>> http://mailman.isi.edu/pipermail/ns-users/2004-July/043516.html
>>> http://mailman.isi.edu/pipermail/ns-users/2006-March/054712.html
>>>
>>> Best Regards
>>> Mubashir Husain Rehmani
>>>
>>>
>>> On 22 February 2011 18:17, Érico Porto wrote:
>>>
Has anyone understood how this works? I found 158 matches to calls of
Mac802_11::recv,.
Any help appreciated.
Érico V. Porto
On Mon, Feb 21, 2011 at 2:38 PM, Érico Porto >>> >wrote:
> I was looking at the mac802_11.cc implementation, and looking at the
> following function:
>
> Mac802_11::recv
>
> It seems that it also has another type of decision clause:
>
> if(pktRx_->txinfo_.RxPr / p->txinfo_.RxPr >= p->txinfo_.CPThresh) {
> capture(p);
> } else {
> collision(p);
> }
>
> From this code I think a package can interfere with another in a one
on one
> way, so multiple packages don't sum their energy to create a noisy
> environment.
>
> Also, if one package Receive power is CPThresh times bigget the
another,
> than it is received, otherwise, it as marked as colision and
discarded.
>
> Érico V. Porto
>
>
>
> On Mon, Feb 21, 2011 at 2:05 PM, Érico Porto <
ericoporto2...@gmail.com>wrote:
>
>> Hello everyone,
>>
>> I was looking at how the NS-2 implements the interference that a noda
has
>> over the other... So I map this functions:
>>
>> (phy.cc) Phy::recv ->
>> (wireless-phy.cc) WirelessPhy::sendDown(packet *p) ->
>> (channel.cc) WirelessChannel::Recvd(packet *p) ->
>> WirelessChannel::SendUp(packet* P, Phy * tifp) ->
>> getAffectedNodes(mtnode, distCST_ + 5, &numAffectedNodes) ->
>> distCST_ = wifp->getDist( wifp ->getPowerMonitorTresh(),
wifp->getPt(),
>> wifp->getAntennaRxGain(), wifp
Re: [ns] interference model
Hello Erico,
Generally speaking, the packet flow is: when a packet is sent by the
particular node from the network layer (down direction), it is first
received by the 802_11::recv. In the 802_11::recv, the direction of the
particular packet is checked, if it is down direction, the 802_11::send is
called. If the packet is up direction (means that the packet is received
from the phy layer), several conditions are checked including the including
the state of the channel and incoming power.
Note that 802_11::recv (packet direction up) is called by all the nodes
[i.e. packet is received by all the nodes] that are within the carrier
sensing range i.e. approx. 2 times the transmission range and then in the
packet, the error() bit is marked as 1 for those nodes that are outside the
transmission range of the node and has some errors or noise. [In previous
versions of ns2, the ch->error() bit is marked at the mac layer, but now it
is moved to physical layer ]. See ch->error(). Note that the ch->error() is
used to include the noise, bit erros: see wireless-phy.cc file,
WirelessPhy::sendUp(Packet *p) function. Moreover, in the same file, you can
see the modulation, FECs etc
Regards
Mubashir Husain Rehmani
Lip6/UPMC, Paris, France
On 22 February 2011 19:09, Érico Porto wrote:
> I understood these parameters, but the problem is, when a msg is sent, and
> we have a packet, the 802_11::recv will be called by which nodes?
>
> And why the wireless channel nodes in range when a msg is sent get delay
> time increased by a factor distance/speed of light, and why this happens
> inside a square?
>
> Also I'm not seeing any reference to noise, so it seems that it is not even
> a AWGN channel.
>
> Érico V. Porto
>
>
>
> On Tue, Feb 22, 2011 at 2:39 PM, Mubashir Rehmani wrote:
>
>> Please look at this also written by Kimaya on ns2 old mailing list:
>>
>> RXThresh_ is the reception threshold. If the received signal strength is
>> greater than this threshold, the packet can be successfully received.
>>
>>
>>
>> CSThresh_ is the carrier sensing threshold. If received signal strength is
>>
>> greater than this threshold, the packet transmission can be
>> sensed. However, the packet cannot be decoded unless signal strength is
>>
>>
>>
>> greater than RXThresh_.
>>
>> CPThresh_ refers to the capture phenomenon. If two packets are received
>>
>> simultaneously, i.e. they collide, it is still possible to receive the
>> 'stronger' packet if its signal strength is CPThresh_ times the other
>>
>>
>>
>> packet. For example, if CPThresh_ is 10.0, the stronger packet in a
>>
>> collision can be decoded if its signal strength is at least 10.0 times
>> that of the other packet; otherwise, both packets are lost in the
>> collision.
>>
>>
>>
>> Hope that helps.
>>
>> Kimaya
>>
>>
>>
>> On 22 February 2011 18:33, Mubashir Rehmani wrote:
>>
>>> Hello Erico,
>>>
>>> Here are some dicussions regarding RXThresh_ that may help you
>>> http://overegoz.tistory.com/668
>>>
>>> http://www.lastking.net/54?TSSESSIONlastkingnet=5ec6c07a691774bd721516037eafa42b
>>> http://mailman.isi.edu/pipermail/ns-users/2004-July/043516.html
>>> http://mailman.isi.edu/pipermail/ns-users/2006-March/054712.html
>>>
>>> Best Regards
>>> Mubashir Husain Rehmani
>>>
>>>
>>> On 22 February 2011 18:17, Érico Porto wrote:
>>>
Has anyone understood how this works? I found 158 matches to calls of
Mac802_11::recv,.
Any help appreciated.
Érico V. Porto
On Mon, Feb 21, 2011 at 2:38 PM, Érico Porto >>> >wrote:
> I was looking at the mac802_11.cc implementation, and looking at the
> following function:
>
> Mac802_11::recv
>
> It seems that it also has another type of decision clause:
>
> if(pktRx_->txinfo_.RxPr / p->txinfo_.RxPr >= p->txinfo_.CPThresh) {
> capture(p);
> } else {
> collision(p);
> }
>
> From this code I think a package can interfere with another in a one
on one
> way, so multiple packages don't sum their energy to create a noisy
> environment.
>
> Also, if one package Receive power is CPThresh times bigget the
another,
> than it is received, otherwise, it as marked as colision and
discarded.
>
> Érico V. Porto
>
>
>
> On Mon, Feb 21, 2011 at 2:05 PM, Érico Porto <
ericoporto2...@gmail.com>wrote:
>
>> Hello everyone,
>>
>> I was looking at how the NS-2 implements the interference that a noda
has
>> over the other... So I map this functions:
>>
>> (phy.cc) Phy::recv ->
>> (wireless-phy.cc) WirelessPhy::sendDown(packet *p) ->
>> (channel.cc) WirelessChannel::Recvd(packet *p) ->
>> WirelessChannel::SendUp(packet* P, Phy * tifp) ->
>> getAffectedNodes(mtnode, distCST_ + 5, &numAffectedNodes) ->
>> distCST_ = wifp->getDist( wifp ->getPowerMonitorTresh(),
wifp->getPt(),
>> wifp->getAntennaRxGain(), w
[ns] ARQ protocol
Hi, I have tried the ARQ protocol at the following link: http://www.ns2ultimate.com/post/1539258323 But it doesn't give the correct results. The TCP sequence number is always one. Anu
Re: [ns] interference model
I understood these parameters, but the problem is, when a msg is sent, and
we have a packet, the 802_11::recv will be called by which nodes?
And why the wireless channel nodes in range when a msg is sent get delay
time increased by a factor distance/speed of light, and why this happens
inside a square?
Also I'm not seeing any reference to noise, so it seems that it is not even
a AWGN channel.
Érico V. Porto
On Tue, Feb 22, 2011 at 2:39 PM, Mubashir Rehmani wrote:
> Please look at this also written by Kimaya on ns2 old mailing list:
>
> RXThresh_ is the reception threshold. If the received signal strength is
> greater than this threshold, the packet can be successfully received.
>
>
> CSThresh_ is the carrier sensing threshold. If received signal strength is
>
> greater than this threshold, the packet transmission can be
> sensed. However, the packet cannot be decoded unless signal strength is
>
>
> greater than RXThresh_.
>
> CPThresh_ refers to the capture phenomenon. If two packets are received
>
> simultaneously, i.e. they collide, it is still possible to receive the
> 'stronger' packet if its signal strength is CPThresh_ times the other
>
>
> packet. For example, if CPThresh_ is 10.0, the stronger packet in a
>
> collision can be decoded if its signal strength is at least 10.0 times
> that of the other packet; otherwise, both packets are lost in the
> collision.
>
>
> Hope that helps.
>
> Kimaya
>
>
>
> On 22 February 2011 18:33, Mubashir Rehmani wrote:
>
>> Hello Erico,
>>
>> Here are some dicussions regarding RXThresh_ that may help you
>> http://overegoz.tistory.com/668
>>
>> http://www.lastking.net/54?TSSESSIONlastkingnet=5ec6c07a691774bd721516037eafa42b
>> http://mailman.isi.edu/pipermail/ns-users/2004-July/043516.html
>> http://mailman.isi.edu/pipermail/ns-users/2006-March/054712.html
>>
>> Best Regards
>> Mubashir Husain Rehmani
>>
>>
>> On 22 February 2011 18:17, Érico Porto wrote:
>>
>>>
>>> Has anyone understood how this works? I found 158 matches to calls of
>>> Mac802_11::recv,.
>>>
>>> Any help appreciated.
>>>
>>> Érico V. Porto
>>>
>>>
>>> On Mon, Feb 21, 2011 at 2:38 PM, Érico Porto >> >wrote:
>>>
>>> > I was looking at the mac802_11.cc implementation, and looking at the
>>> > following function:
>>> >
>>> > Mac802_11::recv
>>> >
>>> > It seems that it also has another type of decision clause:
>>> >
>>> > if(pktRx_->txinfo_.RxPr / p->txinfo_.RxPr >= p->txinfo_.CPThresh) {
>>> > capture(p);
>>> > } else {
>>> > collision(p);
>>> > }
>>> >
>>> > From this code I think a package can interfere with another in a one on
>>> one
>>> > way, so multiple packages don't sum their energy to create a noisy
>>> > environment.
>>> >
>>> > Also, if one package Receive power is CPThresh times bigget the
>>> another,
>>> > than it is received, otherwise, it as marked as colision and discarded.
>>> >
>>> > Érico V. Porto
>>> >
>>> >
>>> >
>>> > On Mon, Feb 21, 2011 at 2:05 PM, Érico Porto >> >wrote:
>>> >
>>> >> Hello everyone,
>>> >>
>>> >> I was looking at how the NS-2 implements the interference that a noda
>>> has
>>> >> over the other... So I map this functions:
>>> >>
>>> >> (phy.cc) Phy::recv ->
>>> >> (wireless-phy.cc) WirelessPhy::sendDown(packet *p) ->
>>> >> (channel.cc) WirelessChannel::Recvd(packet *p) ->
>>> >> WirelessChannel::SendUp(packet* P, Phy * tifp) ->
>>> >> getAffectedNodes(mtnode, distCST_ + 5, &numAffectedNodes) ->
>>> >> distCST_ = wifp->getDist( wifp ->getPowerMonitorTresh(),
>>> wifp->getPt(),
>>> >> wifp->getAntennaRxGain(), wifp->getAntennaTxGain(), highestZ,
>>> highestZ,
>>> >> wifp->getL() )
>>> >>
>>> >> The getDist function implementation depends on what model is being
>>> used:
>>> >>
>>> >> (propagation.cc) [freespace/friss] lambda/(4pi) * sqrt(Pt Gt Gr / Pr
>>> L)
>>> >> (tworayground.cc) {tworayground] hr/ht sqrt(Pt Gt Gr / Pr)
>>> >>
>>> >> Also I was reading this :
>>> >> http://www.cs.binghamton.edu/~kliu/research/ns2code/note.pdf ; and
>>> >> looking at that and at the code, it became strange that, looking at
>>> the
>>> >> code, a node affects the nodes in a SQUARE centered in the one which
>>> is
>>> >> sending, with a distance from the getDist plus 5.
>>> >>
>>> >> I may be wrong, but a Node was suposed to interfere with another, with
>>> a
>>> >> bigger distance than just the Friss model distance - something like
>>> twice
>>> >> that distance...
>>> >>
>>> >> Érico V. Porto
>>> >>
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Mubashir Husain Rehmani
>>
>>
>>
>
>
> --
> Mubashir Husain Rehmani
>
>
>
Re: [ns] interference model
Has anyone understood how this works? I found 158 matches to calls of
Mac802_11::recv,.
Any help appreciated.
Érico V. Porto
On Mon, Feb 21, 2011 at 2:38 PM, Érico Porto wrote:
> I was looking at the mac802_11.cc implementation, and looking at the
> following function:
>
> Mac802_11::recv
>
> It seems that it also has another type of decision clause:
>
> if(pktRx_->txinfo_.RxPr / p->txinfo_.RxPr >= p->txinfo_.CPThresh) {
> capture(p);
> } else {
> collision(p);
> }
>
> From this code I think a package can interfere with another in a one on one
> way, so multiple packages don't sum their energy to create a noisy
> environment.
>
> Also, if one package Receive power is CPThresh times bigget the another,
> than it is received, otherwise, it as marked as colision and discarded.
>
> Érico V. Porto
>
>
>
> On Mon, Feb 21, 2011 at 2:05 PM, Érico Porto wrote:
>
>> Hello everyone,
>>
>> I was looking at how the NS-2 implements the interference that a noda has
>> over the other... So I map this functions:
>>
>> (phy.cc) Phy::recv ->
>> (wireless-phy.cc) WirelessPhy::sendDown(packet *p) ->
>> (channel.cc) WirelessChannel::Recvd(packet *p) ->
>> WirelessChannel::SendUp(packet* P, Phy * tifp) ->
>> getAffectedNodes(mtnode, distCST_ + 5, &numAffectedNodes) ->
>> distCST_ = wifp->getDist( wifp ->getPowerMonitorTresh(), wifp->getPt(),
>> wifp->getAntennaRxGain(), wifp->getAntennaTxGain(), highestZ, highestZ,
>> wifp->getL() )
>>
>> The getDist function implementation depends on what model is being used:
>>
>> (propagation.cc) [freespace/friss] lambda/(4pi) * sqrt(Pt Gt Gr / Pr L)
>> (tworayground.cc) {tworayground] hr/ht sqrt(Pt Gt Gr / Pr)
>>
>> Also I was reading this :
>> http://www.cs.binghamton.edu/~kliu/research/ns2code/note.pdf ; and
>> looking at that and at the code, it became strange that, looking at the
>> code, a node affects the nodes in a SQUARE centered in the one which is
>> sending, with a distance from the getDist plus 5.
>>
>> I may be wrong, but a Node was suposed to interfere with another, with a
>> bigger distance than just the Friss model distance - something like twice
>> that distance...
>>
>> Érico V. Porto
>>
>
>
Re: [ns] queue length measure
Hello,
I'm not sure if this procedure will work, because in wired network,
queue are "associated" with links, instead of nodes, so I don't think it
works.
By the way, for wired network you have the queue monitor, a proper
object from NS2 that makes this job (even better, because you can access
more variables, like bytes received, sent, and so on I think), and that
it's "associated" with every link you need to monitor.
Search for this object in the documentation, I'm pretty sure it will
helps you more.
If I'm wrong and anyone knows the answer please correct us.
Regards!
Leo Sánchez.
El 22/02/2011 17:43, Alenezi 10 escribió:
> Can I use same procedure for wire network ?
>
>
> Sent from my iPhone
>
> On Feb 22, 2011, at 7:36 PM, Leo Sánchez wrote:
>
>> Hello,
>> I've found a way to monitor the queue in wireless nodes.
>> First, read this topic:
>> http://old.nabble.com/how-to-monitor-the-queue-on-a-wireless-node-to30608840.html
>> And do the things explained in:
>> http://hpds.ee.ncku.edu.tw/~smallko/ns2/qa_en.htm except the last step
>> (modifying the TCL file).
>> Now, you must be able to access to curq_ variable from your TCL file. To
>> do this, you could create a procedure to record the evolution of this
>> variable in time, maybe something like this.
>>
>> proc record {} {
>> # queuefile is your file for trace the queue.
>> global ns_ node_ queuefile
>> settime 1
>> setnow[$ns_now]
>> # Obtain the queue objet for this node (you can do this for every node you
>> want).
>> setq0[$node_(0)setifq_(0)]
>> # Obtain the variable curq_ from queue object.
>> setqlen0[$q0setcurq_]
>> # Write into the file.
>> puts $queuefile "$now $qlen0"
>> $ns_at [expr $now+$time] "record"
>> }
>>
>>
>> I'm a new user too in NS2, and I was trying to achieve this for days.
>> Finally I figure out how to access this variable from TCL but only after
>> hard work and not finding any answer to most of topics related to this
>> one (except the link I provide you).
>> Maybe there is another way (more efficient or better) but at least you
>> have this one.
>> Hope this helps.
>> If you need further information, don't hesitate to ask, and I'll try to
>> answer you if I can.
>>
>> Regards!
>> Leo Sánchez.
>>
>> PS: sorry if there is any mistake, I'm not fluent in English.
>>
>>
>>
>> El 22/02/2011 16:16, Ahmad escribió:
>>> I wonder too. If you ever find the answer plz fwd. Thanks
>>>
>>> On 2011-02-21, at 9:37 AM, Akalyadevi
>>> Karpagavinayagam wrote:
>>>
hi
how the queue length of each node was calculated in wireless network?
how will alter the queue length ?
regards
akalya
Re: [ns] queue length measure
Hello,
I've found a way to monitor the queue in wireless nodes.
First, read this topic:
http://old.nabble.com/how-to-monitor-the-queue-on-a-wireless-node-to30608840.html
And do the things explained in:
http://hpds.ee.ncku.edu.tw/~smallko/ns2/qa_en.htm except the last step
(modifying the TCL file).
Now, you must be able to access to curq_ variable from your TCL file. To
do this, you could create a procedure to record the evolution of this
variable in time, maybe something like this.
proc record {} {
# queuefile is your file for trace the queue.
global ns_ node_ queuefile
set time 1
set now [$ns_ now]
# Obtain the queue objet for this node (you can do this for every node you
want).
set q0 [$node_(0) set ifq_(0)]
# Obtain the variable curq_ from queue object.
set qlen0 [$q0set curq_]
# Write into the file.
puts $queuefile "$now $qlen0"
$ns_ at [expr $now+$time] "record"
}
I'm a new user too in NS2, and I was trying to achieve this for days.
Finally I figure out how to access this variable from TCL but only after
hard work and not finding any answer to most of topics related to this
one (except the link I provide you).
Maybe there is another way (more efficient or better) but at least you
have this one.
Hope this helps.
If you need further information, don't hesitate to ask, and I'll try to
answer you if I can.
Regards!
Leo Sánchez.
PS: sorry if there is any mistake, I'm not fluent in English.
El 22/02/2011 16:16, Ahmad escribió:
> I wonder too. If you ever find the answer plz fwd. Thanks
>
> On 2011-02-21, at 9:37 AM, Akalyadevi Karpagavinayagam
> wrote:
>
>> hi
>>
>>
>> how the queue length of each node was calculated in wireless network?
>>
>> how will alter the queue length ?
>>
>>
>> regards
>> akalya
>>
Re: [ns] queue length measure
I wonder too. If you ever find the answer plz fwd. Thanks On 2011-02-21, at 9:37 AM, Akalyadevi Karpagavinayagam wrote: > > hi > > > how the queue length of each node was calculated in wireless network? > > how will alter the queue length ? > > > regards > akalya >
Re: [ns] SENDING A MSG TO OTHER NODES.
I am new to ns2 so this may not be the optimal method but i call tcl from that node java code and this tcl has access to all nodes so can call the intended node consequently Best of luck On 2011-02-22, at 4:58 AM, Suman paul choudhury wrote: > > dear all > > How does a node sends an instruction message to other node? is there any > NS-2 command for sending such instruction message. > Any such example would be really helpful. > > thanking you > > regards > Suman
Re: [ns] [Ns-developers] otcl cannot find X11
On Tue, Feb 22, 2011 at 8:56 PM, wrote: > Install libxt-dev. > thanks very much > (I've often wondered why otcl requires X11...) > in this src package otkAppInit.c requires tk, then x11. Problems with not being able to find X11 under debian/ubuntu often turn out > to be debian/ubuntu packaging problems - missing -dev headers, existing > source files including headers that are in some other not-installed -dev > package, etc. > It's a debian unstable packaging problem, not an otcl problem. > > > > > > -Original Message- > > From: ns-developers-boun...@isi.edu > > [mailto:ns-developers-boun...@isi.edu] On Behalf Of YunQiang Su > > Sent: 22 February 2011 12:47 > > To: ns-users; ns-developers > > Subject: [Ns-developers] otcl cannot find X11 > > > > when build otcl under debian unstable, it can not find X11. > > > > > > > > -- Forwarded message -- > > From: Lucas Nussbaum > > Date: Tue, Feb 22, 2011 at 6:31 AM > > Subject: Bug#614438: otcl: FTBFS: ld: cannot find -lXbsd > > To: sub...@bugs.debian.org > > > > > > Source: otcl > > Version: 1.14~RC3+dfsg1-1 > > Severity: serious > > Tags: squeeze sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20110221 qa-ftbfs > > Justification: FTBFS on amd64 > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed > > to build on amd64. > > > > Relevant part: > > > g++: '-V' option must have argument > > > configure:3175: $? = 1 > > > configure:3178: checking whether we are using the GNU C++ compiler > > > configure:3207: g++ -c -g -O2 conftest.cpp >&5 > > > configure:3214: $? = 0 > > > configure:3231: result: yes > > > configure:3240: checking whether g++ accepts -g > > > configure:3270: g++ -c -g conftest.cpp >&5 > > > configure:3277: $? = 0 > > > configure:3378: result: yes > > > configure:3407: checking how to run the C preprocessor > > > configure:3447: gcc -E conftest.c > > > configure:3454: $? = 0 > > > configure:3485: gcc -E conftest.c > > > conftest.c:8:28: error: ac_nonexistent.h: No such file or directory > > > configure:3492: $? = 1 > > > configure: failed program was: > > > | /* confdefs.h. */ > > > | #define PACKAGE_NAME "" > > > | #define PACKAGE_TARNAME "" > > > | #define PACKAGE_VERSION "" > > > | #define PACKAGE_STRING "" > > > | #define PACKAGE_BUGREPORT "" > > > | /* end confdefs.h. */ > > > | #include > > > configure:3525: result: gcc -E > > > configure:3554: gcc -E conftest.c > > > configure:3561: $? = 0 > > > configure:3592: gcc -E conftest.c > > > conftest.c:8:28: error: ac_nonexistent.h: No such file or directory > > > configure:3599: $? = 1 > > > configure: failed program was: > > > | /* confdefs.h. */ > > > | #define PACKAGE_NAME "" > > > | #define PACKAGE_TARNAME "" > > > | #define PACKAGE_VERSION "" > > > | #define PACKAGE_STRING "" > > > | #define PACKAGE_BUGREPORT "" > > > | /* end confdefs.h. */ > > > | #include > > > configure:3639: checking for grep that handles long lines and -e > > > configure:3699: result: /bin/grep > > > configure:3704: checking for egrep > > > configure:3768: result: /bin/grep -E > > > configure:3773: checking for ANSI C header files > > > configure:3803: gcc -c -g -O2 conftest.c >&5 > > > configure:3810: $? = 0 > > > configure:3909: gcc -o conftest -g -O2 conftest.c >&5 > > > configure:3913: $? = 0 > > > configure:3919: ./conftest > > > configure:3923: $? = 0 > > > configure:3941: result: yes > > > configure:3965: checking for sys/types.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for sys/stat.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for stdlib.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for string.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for memory.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for strings.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for inttypes.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for stdint.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:3965: checking for unistd.h > > > configure:3986: gcc -c -g -O2 conftest.c >&5 > > > configure:3993: $? = 0 > > > configure:4010: result: yes > > > configure:4029: checking for string.h > > > configure:4036: result: yes > > > configure:4180: checking for main in -lXbsd > > > c
[ns] tclcl-1.17 make failed! Exiting
Hi. I have a problem while installing Tclcl 1.17 in ns 2.29 in Ubuntu 10.04 But in make I get this error: can anyone hwlp me with that g++ -c -DNO_TK -DNDEBUG -DUSE_SHM -DHAVE_LIBOTCL1_11 -DHAVE_OTCL_H -DHAVE_LIBTK8_4 -DHAVE_TK_H -DHAVE_LIBTCL8_4 -DHAVE_TCLINT_H -DHAVE_TCL_H -DHAVE_CONFIG_H -I. -I/home/sina/Desktop/ns-allinone-2.29/otcl-1.11 -I/home/sina/Desktop/ns-allinone-2.29/include -I/home/sina/Desktop/ns-allinone-2.29/include -I/home/sina/Desktop/ns-allinone-2.29/include -o Tcl.o Tcl.cc Tcl.cc: In member function ‘void Tcl::eval(char*)’: Tcl.cc:182:8: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc: In member function ‘int TclObject::traceVar(const char*, TclObject*)’: Tcl.cc:421:50: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc: In static member function ‘static int TclClass::create_shadow(void*, Tcl_Interp*, int, const char**)’: Tcl.cc:509:57: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc:511:61: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc: In static member function ‘static int TclClass::dispatch_instvar(void*, Tcl_Interp*, int, const char**)’: Tcl.cc:566:35: error: invalid conversion from ‘const char*’ to ‘char*’ Tcl.cc:571:72: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc: In member function ‘virtual void TclClass::bind()’: Tcl.cc:603:60: warning: deprecated conversion from string constant to ‘char*’ Tcl.cc:605:60: warning: deprecated conversion from string constant to ‘char*’ make: *** [Tcl.o] Error 1
[ns] SENDING A MSG TO OTHER NODES.
dear all How does a node sends an instruction message to other node? is there any NS-2 command for sending such instruction message. Any such example would be really helpful. thanking you regards Suman
