awk script- delay 계산

참고 : http://www.winlab.rutgers.edu/~zhibinwu/html/ns_trace.html
작성 : 2006.12.17 by 임헌정
http://www.4ellene.net

CMU use a special fomat. Basically, you could 

$ns use-newtrace


to generate the new trace and the detailed explanation could be found

in Ns Manual.By default, old trace format is used. We need to analyze

the source code ./trace/cmu-trace.cc to understand it completely.

For instance, the function format_ip will explain the trace of IP part.




void

CMUTrace::format_ip(Packet *p, int offset)

{

        struct hdr_cmn *ch = HDR_CMN(p);

        struct hdr_ip *ih = HDR_IP(p);


        // hack the IP address to convert pkt format to hostid format

        // for now until port ids are removed from IP address. -Padma.

        int src = Address::instance().get_nodeaddr(ih->saddr());

        int dst = Address::instance().get_nodeaddr(ih->daddr());


    ............


}


void

CMUTrace::format_mac(Packet *p, int offset)

{


else {

                sprintf(pt_->buffer() + offset,

                        " [%x %x %x %x] ",

                        //*((u_int16_t*) &mh->dh_fc),

                        mh->dh_duration,


                        ETHER_ADDR(mh->dh_ra),

                        ETHER_ADDR(mh->dh_ta),




                        GET_ETHER_TYPE(mh->dh_body));

        }

......


}




A typical trace for a CBR traffic is:


s 20.000000000 _0_ AGT  --- 6 cbr 512 [0 0 0 0] ------- [0:0 1:0 32 0]

[0] 0 0

r 20.000000000 _0_ RTR  --- 6 cbr 512 [0 0 0 0] ------- [0:0 1:0 32 0]

[0] 0 0

s 20.000000000 _0_ RTR  --- 6 cbr 532 [0 0 0 0] ------- [0:0 1:0 32 1]

[0] 0 0

s 20.000275000 _0_ MAC  --- 6 cbr 584 [13a 1 0 800] ------- 

[0:0 1:0 32 1] [0] 0 0

r 20.004947063 _1_ MAC  --- 6 cbr 532 [13a 1 0 800] ------- 

[0:0 1:0 32 1] [0] 1 0

s 20.004957063 _1_ MAC  --- 0 ACK 38 [0 0 0 0]

r 20.004972063 _1_ AGT  --- 6 cbr 532 [13a 1 0 800] ------- 

[0:0 1:0 32 1] [0] 1 0

r 20.005261125 _0_ MAC  --- 0 ACK 38 [0 0 0 0]



A typical awk code for analyzing traces is:


For a topology involve 4 flows with distinguishing source and 

destination nodes,

this awkcode gets throughout data and put in wu.dat file


[예제] 


BEGIN {counter1 = 0;}

$1~/r/ && $2>50 && $2< 100  && /_2_/ && /AGT/  {   counter1 += 

($8- 20)

                       size = $8 - 20 }

END {

     print (size , counter1*8/(50) )  >> "wu.dat"}



로 delay_throughout.awk 파일 생성 


$ awk -f delay_though.awk aodv_3nodes_tcp.tr 실행 

# 50~100ms 사이에, 2노드로 수신한 패킷들




BEGIN {counter1 = 0; counter2 = 0; counter3 = 0; counter4 = 0;}

$1~/r/ && $2>50 && $2< 100  && /_12_/ && /AGT/  {   counter1 += ($8- 20)

                       size = $8 - 20 }

$1~/r/ && $2>50 && $2 <100 && /_13_/ && /AGT/  {   counter2 += ($8- 20)

                       size = $8 - 20 }

$1~/r/ && $2>50 && $2<100 && /_14_/ && /AGT/  {   counter3 += ($8- 20)

                       size = $8 - 20 }

$1~/r/ && $2>50 && $2<100 && /_15_/ && /AGT/  {   counter4 += ($8- 20)

                       size = $8 - 20 }


END {

     print (size , counter1*8/(50), counter2*8/50, counter3*8/(50), counter4*8/50,

                 (counter1+counter2+counter3+counter4)*8/50 )  >> "wu.dat"}



To analyze throughout or delay in a finite time duration,


we need extract send and receive time from the trace file


[예제] 
$ awk '$2>100 && $2 < 150 && (/_0_/ || /_2_/)  &&  /AGT/    {  print
 $1, $2, $6  > "dst2.tr" }' aodv_3nodes_tcp.tr



$2>100 && $2 < 150 && (/_6_/ || /_2_/)  &&  /AGT/    {  print $1, $2, $6  > "dst2.tr" }

$2>100 && $2 <150 && (/_0_/ || /_9_/)  &&  /AGT/    {   print $1, $2, $6  > "dst9.tr" }

$2>100 && $2 <150 && (/_12_/ || /_3_/)  &&  /AGT/    {   print $1, $2, $6  > "dst3.tr" }

$2>100 && $2 <150 && (/_10_/ || /_4_/)  &&  /AGT/    {   print $1, $2, $6  > "dst4.tr" }

$2>100 && $2 <150 && (/_11_/ || /_8_/)  &&  /AGT/    {   print $1, $2, $6  > "dst8.tr" }



The respective new trace files such as "dst2.tr" will keep time, "s'" 

or "r" and, "index", 

From that we could use a program to calculate the mean of delay.

The files is here: 

 


And to use this C code:

$ gcc delay.c -o delaycal

$ ./delaycal dst2.tr wu0.dat wu1.dat

Analysis of 802.11 MAC code in NS-2

0. MAC in ns-2

LAN is within Berkeley Architecture, WLAN cannot create with “newLan” command
Ethernet could be created as a LAN with common bandwidth and delay.
 

1. The general structure of MAC

• pktTx_ 
• pktRx_
• Macstate_ :
• index_  : mac address
  

• recv (packet, handler)
  • This is the entry from upper target (a callback handler is given as a parameter) to send a packet to MAC. After the MAC transmit this packet successfully, it will use this callback handler to inform the upper target that MAC is idle and  give another packet if there are packets buffered.
    
• SendUp
  • entry for receiving a packet. Sendup is function is directly called by the lower target of MAC, might be "netif" or "phy". And this function directly calls the upper_target. Because the uplink  to upper_target does not involve any phsical transmission delay, it does not need any timer and state change here. The question is that when the MAC is in MAC_RECV state? The answer is: The MAC here is supposed to be full-duplex and receive can be happened simultaneously. it does not care about collisions etc. This is a general MAC class
    
• SendDown
  • used to sending packet down. Called by recv().init a timer for tx, and the timer handler is defined to call resume().
    
• Handler* callback_;
  • when MAC is idle, the upper target has to be callback.
• Resume()
  • When tx timer out, reset MAC as idle state and callback.
    
• Discard
  • When a packet has to be drop, the drop_ (NsObject*) of bi-connector class has to be called to handle this, usually drop (p, why) is used. Why is a string of drop reason, in cmu-trace.h. three-character string is defined to describe those reasons in the trace file, such as "BSY", "CBK"....
    

2. The 802.11 MAC

• pktTx_ (inherited from Mac class): 
• pktRx_(inherited from Mac class):
  
• pktCtrl_
• pktRTS_
  

• recv(): the recv() function of MAC class has been overridden. Here, recv() means an incoming packet from both physical layer and upper layer.
  
• send(): this function is called by recv() when it get a packet supposed to sending down.  Similarly, a callback handler is given as a parameter. Immediately, the sendDATA(p) function is called to generate an appropriate mac_header for this packet, and set this to pktTx_. Then,  follew the CSMA/CA procedures to get this packet sent.
• sendDATA(). to compose a DATA MAC frame and set it as pktTx_
• recvDATA(). When heard a DATA MAC frame, hand it to upper layer.
  

void

Mac802_11::tx_resume()

{

 .....

else if(callback_) {

        Handler *h = callback_;

        callback_ = 0;

        h->handle((Event*) 0);

    }

    // change wrt Mike's code

    //SET_TX_STATE(MAC_IDLE);

   setTxState(MAC_IDLE);

}

void QueueHandler::handle(Event*)

{

        queue_.resume();

}


void Queue::resume()

{

        Packet* p = deque();

        if (p != 0) {

                target_->recv(p, &qh_);

        } else {

                if (unblock_on_resume_)

                        blocked_ = 0;

                else

                        blocked_ = 1;

        }

}

Backoff

The backoff implementation in mac-802_11.cc does not comply with the standard. Basically, this is due to the introduction of a defer timer. The defertimer is set in send() and after a packet transmission finishes. The deferred time value is usually (DIFS+rTime) where rTime is as same as the selection of backoff timeslots from CW (Contention Window). However, the defertimer is never paused or resumed.

So, after a packet transmission, according to the IEEE 802.11 standard, the node should do backoff immediately. here in ns-code, the defertime is first set. And after timer out, in check_pktTx() function. if the channel is not idle, a backoff timer is set. Therefore, here exists a double backoff problem. Also, according to IEEE 802.11 standard, a node should access channel directly if it sense the channel idle and still idle after at least DIFS time. Here, ns-code also deviates from the standard and add an additional rTime before sending DATA or RTS.
 
Determine the transmission time
 
txtime is calculated from the "size" variable in common header. Because all headers are present in the packet no matter what layer it is. Thus, the only way to know the packet size is to add or subtract some bytes in hdr_cmn->size(); In 802.11 MAC code, in recvDATA(), the 802.11 header size will be subtracted. And in SendDATA(), a 80211_hdr_length will be added.

Transmission Failure:

In both RetransmitRTS and RetransmitDATA functions, it is necessary to deal a packet drop :

if(ssrc_ >= macmib_.getShortRetryLimit()) {

		discard(pktRTS_, DROP_MAC_RETRY_COUNT_EXCEEDED); pktRTS_ = 0;

		/* tell the callback the send operation failed 

		   before discarding the packet */

		hdr_cmn *ch = HDR_CMN(pktTx_);

		if (ch->xmit_failure_) {

                        /*

                         *  Need to remove the MAC header so that 

                         *  re-cycled packets don't keep getting

                         *  bigger.

                         */

			// change wrt Mike's code

                        //ch->size() -= ETHER_HDR_LEN11;

			ch->size() -= phymib_.getHdrLen11();

                        ch->xmit_reason_ = XMIT_REASON_RTS;

                        ch->xmit_failure_(pktTx_->copy(),

                                          ch->xmit_failure_data_);  //callback by upperlayer
                }
		//printf("(%d)....discarding RTS:%x\n",index_,pktRTS_);
		discard(pktTx_, DROP_MAC_RETRY_COUNT_EXCEEDED); pktTx_ = 0;
		ssrc_ = 0;
		rst_cw();
	} 

So, it is a way to let upper layer , such as DSR routing to know there is a route-error and need to send a route-error message.

Frame Formats in ns-2

The 802.11 header in ns-2 is not conform to the 802.11 standard. It is a different one. Thus, this overhead cannot be regarded as authentic as that of
the experiment. And the throughput measurements also seems different.

Other IEEE 802.11 features

RTS/CTS is an important part of code. There are functions like sendRTS ( is to form a RTS ctrl packrt) , retransmitRTS...... Basically it has to compare with RTSThreshold first, if the size is small than the threshold, there is no" virtual carrier sense" scheme used.

[ns] Dropping Packets with RTR CBK

• Previous message: [ns] Dropping Packets with RTR CBK
• Next message: [ns] how to send 802.16 undetermined size Control messages in ns2
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

It means that the MAC layer couldn't successfully deliver the packet. You can 
find the reasons for this at the bottom of this page: 
http://masimum.inf.um.es/nsrt-howto/html/node23.html

Regards,
fran

P.S: answers to frequent questions like this can be easily found with 
http://www.isi.edu/nsnam/htdig/search.html

On Tuesday 19 September 2006 11:48, michelenuti at alice.it wrote:
> Hi ns users,
> does anybody know what does it mean when a TCP packet is dropped and in the
> trace file is indicated as RTR CBK?
>
> Thanks a lot,
> Michele Nuti

• Previous message: [ns] Dropping Packets with RTR CBK
• Next message: [ns] how to send 802.16 undetermined size Control messages in ns2
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: segmentation fault (core dumped) using ZRP in ns-2.27