hii,
when i run "make" command in ns directory then i
get following errors, so please kindly give me
solution to remove following errors:
for i in indep-utils/cmu-scen-gen/setdest
indep-utils/webtrace-conv/dec
indep-utils/webtrace-conv/epa
indep-utils/webtrace-conv/nlanr
indep-utils/webtrace-conv/ucb; do ( cd $i; make all; )
done
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/cmu-scen-gen/setdest'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/cmu-scen-gen/setdest'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/dec'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/dec'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/epa'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/epa'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/nlanr'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/nlanr'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/ucb'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/ucb'
--- [EMAIL PROTECTED] wrote:
> Send Ns-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
> http://mailman.isi.edu/mailman/listinfo/ns-users
> or, via email, send a message with subject or body
> 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Ns-users digest..."
>
>
> Today's Topics:
>
> 1. link bandwidth and delay link in ad hoc
> networks (leticia bela)
> 2. Bug in 802.15.4 implementation (Daniele
> Messina)
> 3. including scenario and traffic generator files
> (shalini c. thilakan)
> 4. wired - wireless scenarios (Ira Vollenberg)
> 5. Re: Rate of CBR Traffic ? (Farrag, Osama)
> 6. NAT implementation in NS2 (Amol Dawalbhakta)
> 7. IFQ USE IS CORRECT? (antonis antoniou)
> 8. DSR FRAGMENTATION ERROR (antonis antoniou)
> 9. Re: Bug in 802.15.4 implementation (Daniele
> Messina)
> 10. Set contention window 802.11 from tcl (antonis
> antoniou)
> 11. Re: Bug in 802.15.4 implementation (Ahmad
> Khayyat)
> 12. Re: Problem NOAH with wired cum wireless
> scenario (Naxo)
> 13. urgent : help in getting xgraph (harpreet)
>
>
>
----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Mar 2007 17:04:58 +0100 (CET)
> From: leticia bela <[EMAIL PROTECTED]>
> Subject: [ns] link bandwidth and delay link in ad
> hoc networks
> To: [email protected]
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi all,
>
> I have read articles speaking about the band-width
> of a wireless link and delay of this link in the ad
> hoc networks. but I have not find any explanation on
> the way of calculating them under NS.
> Please If anyone has an idea of this topic to
> help me . It is very important
> I am very grateful for you.
> Thanks in advance
>
>
> ---------------------------------
> D?couvrez une nouvelle fa?on d'obtenir des r?ponses
> ? toutes vos questions ! Profitez des connaissances,
> des opinions et des exp?riences des internautes sur
> Yahoo! Questions/R?ponses.
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Mar 2007 18:27:06 +0100
> From: Daniele Messina <[EMAIL PROTECTED]>
> Subject: [ns] Bug in 802.15.4 implementation
> To: [email protected]
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
> I've found a possible bug / unhandled scenario in
> the 802.15.4 code included
> in version 2.28 and subsequent.
> It is due to a change introduced in the CCA and may
> cause the csma status to
> get locked to "1", with various disastrous
> consequences.
> I think that this may help someone who is working
> with 802.15.4.
> Understanding what follows requires the reader to be
> very familiar with the
> 802.15.4 implementation on ns, both for my english
> ;) and for the
> complicated subject.
> You can skip my explanation and just consider the
> following fix:
> locate this method
>
> void Phy802_15_4::PLME_CCA_request()
> {
> if (trx_state == p_RX_ON)
> {
> //perform CCA
> //refer to sec 6.7.9 for CCA details
> //we need to delay 8 symbols
> CSH.start(1/getRate('s'));
> CCAH.start(8/getRate('s'));
> }
> }
>
> and change this line:
> CSH.start(1/getRate('s'));
> to
> CSH.start(8/getRate('s'));
> Stop.
>
> For those who are interested here is all: consider a
> network entity willing to
> send a data packet. It will issue a
> Mac802_15_4::mcps_data_request, which
> through a series of calls makes the backoff timer
> start with a random time as
> in the following scheme:
>
> Mac802_15_4::mcps_data_request
> [...]
> printf("node %d: CSMA requested by MAC at %f
> \n",index_,NOW);
> csmacaBegin('d');
> \__
> [...]
> csmacaResume();
> *** important: csmacaResume set the status of the
> csma to 99 ***
> \__
> [...]
> csmaca->start
> \__
> [...]
> backoffT->start(wtime);
>
> When the backoff timer expires
> CsmaCA802_15_4::backoffHandler is invoked:
>
> CsmaCA802_15_4::backoffHandler
> [...]
> mac->plme_set_trx_state_request(p_RX_ON);
> [...]
>
> The transceiver is requested to change its state to
> RX_ON
> If the state is successfully changed to RX_ON
>
> void
> Mac802_15_4::PLME_SET_TRX_STATE_confirm(PHYenum
> status)
>
> invokes
>
> csmaca->RX_ON_confirm(status);
>
> which in turn launches the Clear Channel Assessment:
>
> phy->PLME_CCA_request();
>
>
> Now, with version 2.28 a variation in the Clear
> Channel Assessment mechanism
> has been introduced:
> the standard mandates that the channel has to be
> sensed for 8 symbols before
> its status can be determined and in version 2.27 (or
> earlier) the status of
> the channel was tested at the end of the 8th symbol.
> This way it could happen
> that a busy channel in the first symbols but idle at
> the time of the test was
> detected as IDLE instead of BUSY, as it should be in
> this situation.
> Therefore two timers are used now: the first for
> testing the channel status
> at the end of the first symbol and the second for
> giving the CCA response at
> the end of the 8th symbol. A sample of the
> corrisponding code is reported
> here:
>
> void Phy802_15_4::PLME_CCA_request()
> {
> if (trx_state == p_RX_ON)
> {
> //perform CCA
> //refer to sec 6.7.9 for CCA details
> //we need to delay 8 symbols
> CSH.start(1/getRate('s'));
> CCAH.start(8/getRate('s'));
> }
>
=== message truncated ===
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
