Re: [ns] help required regarding analysis of tracefile
Hi, I think you're talking about the awk scripts to interpret the output file given by the simulator, or not? Because that files look for the d. I was talking about the second method: [Method 2---modify C++ code] The basic idea is to insert two fields, sendtime_ and pkt_id_, in the hdr_cmn header. When packets are sent, the packet id and send time is recorded in the sender trace file. Then when packets are received at the destination, the packet id and receiving time is recorded in the receiver trace file. So I prepare two agents, mudp and mudpsink to do the jobs. Mudp is the extension of udp agent. It only overrides the sendmsg function to keep download the packet id and sendtime in the user specified file. The agent by itself records special events needed to calculate Jitter, Data loss and delay. This is a way to measure the channel characterists with UDP flows.
Re: [ns] help required regarding analysis of tracefile
hi thanks for information. but i already tried these codes. if you check the codes these depends upon the 'd' symbole in tracefile. but i got tracefile of eurane which do not have 'd'-drop packet. but i am sure there are some resending of packets. so these doesn't work out for me. thanks for reply. On Mon, 04 Jun 2007 Tiago Junqueira wrote : Hi, I already made the same question, i'm using the NIST WiMAX module, and the trace files are hard to analyse. So what i did was to use this method: http://140.116.72.80/~smallko/ns2/tool_en.htm ,made by Chih-Heng, Ke. With the c++ functions you get 2 files which the default name is rd and sd. This files are easy to analyse, and i'm getting results that look good, but unfortunately i can't tell if it is reliable method to use, i'm just using, the best thing was to know exactly how to interpert the trace files, but for me, at this moment i don't have time. I already asked in the forum but i got no opinions about the method. kindly, Tiago Junqueira
Re: [ns] help required regarding analysis of tracefile
+ 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 - 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 r 1.84471 2 1 cbr 210 --- 1 3.0 1.0 195 600 r 1.84566 2 0 ack 40 --- 2 3.2 0.1 82 602 + 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 - 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 r 1.84609 0 2 cbr 210 --- 0 0.0 3.1 225 610 + 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 d 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 - 1.8461 2 3 cbr 210 --- 0 0.0 3.1 192 511 1st line 610 packet did enque and then deque, but look at 3rd and 4th filed. you'll notice that the packet is from 0 node to 2node . when the packet arrived at 2node, according to its routing, the sorce and destination node became 2node and 3node. this is how you know the routing the packet is using. wish you good luck . CaiJie
Re: [ns] help required regarding analysis of tracefile
Hi, harpreet schrieb: Hi. I want to analysis trace file which looks like (not exactly ) data given below. Here are NS Manual's example + 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 - 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 r 1.84471 2 1 cbr 210 --- 1 3.0 1.0 195 600 r 1.84566 2 0 ack 40 --- 2 3.2 0.1 82 602 + 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 - 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 r 1.84609 0 2 cbr 210 --- 0 0.0 3.1 225 610 + 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 d 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 - 1.8461 2 3 cbr 210 --- 0 0.0 3.1 192 511 r 1.84612 3 2 cbr 210 --- 1 3.0 1.0 196 603 + 1.84612 2 1 cbr 210 --- 1 3.0 1.0 196 603 - 1.84612 2 1 cbr 210 --- 1 3.0 1.0 196 603 + 1.84625 3 2 cbr 210 --- 1 3.0 1.0 199 612 Ok. last field is packet identifier right? and it's unique. But 1st line 610 packet enque and next deque. but 7th line 610 packet again received and enque and dropped. How can this happen? packet identifier is not unique? Line 1: packet #610 enqueued on node 0 Line 2: packet #610 dequeued on node 1 Line 7: packet #610 received on node 2 from node 0 Line 8: packet #610 enqueued on node 2 (now with new destination / next hop 3) Line 9: packet #610 dropped If you receive a packet, the receiver is still the destination. Hope this clearifies you problem., Daniel. -- Dr.-Ing. Daniel Mahrenholz rt-solutions.de GmbH Oberländer Ufer 190a D-50968 Köln Web: www.rt-solutions.de rt-solutions.de networks you can trust.
Re: [ns] help required regarding analysis of tracefile
hi thanks for reply. my problem is there is no inforamtion when data is send from source node and there is no information when packet is dorpped (as there is no s and d in first colum) and i go to analysis this file all analysis files like throughput, jitter and all other work with s and r and d in starting. i can't analysis this tracefile. i am not expert in linux and in ns2. can u please suggest me how to analysis these type of trace files. thanks in advance On Fri, 01 Jun 2007 Daniel Mahrenholz wrote : Hi, harpreet schrieb: Hi. I want to analysis trace file which looks like (not exactly ) data given below. Here are NS Manual's example + 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 - 1.84375 0 2 cbr 210 --- 0 0.0 3.1 225 610 r 1.84471 2 1 cbr 210 --- 1 3.0 1.0 195 600 r 1.84566 2 0 ack 40 --- 2 3.2 0.1 82 602 + 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 - 1.84566 0 2 tcp 1000 --- 2 0.1 3.2 102 611 r 1.84609 0 2 cbr 210 --- 0 0.0 3.1 225 610 + 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 d 1.84609 2 3 cbr 210 --- 0 0.0 3.1 225 610 - 1.8461 2 3 cbr 210 --- 0 0.0 3.1 192 511 r 1.84612 3 2 cbr 210 --- 1 3.0 1.0 196 603 + 1.84612 2 1 cbr 210 --- 1 3.0 1.0 196 603 - 1.84612 2 1 cbr 210 --- 1 3.0 1.0 196 603 + 1.84625 3 2 cbr 210 --- 1 3.0 1.0 199 612 Ok. last field is packet identifier right? and it's unique. But 1st line 610 packet enque and next deque. but 7th line 610 packet again received and enque and dropped. How can this happen? packet identifier is not unique? Line 1: packet #610 enqueued on node 0 Line 2: packet #610 dequeued on node 1 Line 7: packet #610 received on node 2 from node 0 Line 8: packet #610 enqueued on node 2 (now with new destination / next hop 3) Line 9: packet #610 dropped If you receive a packet, the receiver is still the destination. Hope this clearifies you problem., Daniel. -- Dr.-Ing. Daniel Mahrenholz rt-solutions.de GmbH Oberländer Ufer 190a D-50968 Köln Web: www.rt-solutions.de rt-solutions.de networks you can trust. harpreet singh
