Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
Hi, I think that the observed phenomenon depends on how the queue is serviced too. Part of the explanation is that the MAC layer is fetching those packets from the queue in a constant pace. And basically this means that your network isn't loaded enough so that it causes some randomness to be introduced when servicing the queue (ex: back-off timers). That phenomenon depends on which packet caused the queue to be full first, at which rate the packets are coming to the queue and the bandwidth of the MAC layer. Regards, Ilyes Gouta. On 6/8/06, Pedro Vale Estrela [EMAIL PROTECTED] wrote: This is an EXCELENT description of what happens in a non-randomized simulation, and from my experience, I fully agree on that. It is exactly this kind of material that would be very useful for the NS2 Wiki, to store this information permanently! As such, somebody on this list please contribute it to the NS2 wiki pages! Pedro Vale Estrela -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tyler Ross Sent: quinta-feira, 8 de Junho de 2006 16:43 To: Eduardo J. Ortega Cc: ns-users@ISI.EDU Subject: Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths? In reality, sure. What's happening with the simulation though, is that the packets are being sent at the same time. Even though you start the flows sending at t=0 and t=10, when they're both sending, they're sending at the exact same instant. Since internally, everything is handled in a fixed order and nothing is random unless you explicitly make it so, it will always drop the packets from the same source at the same time. Not because it picked the packets from that source to drop, but because that's just the order of things. And once you see how it works for one packet being dropped, the same thing will repeat itself over and over, since no variables are changing. I don't know if that makes sense. Think on the level of one packet (from each source). As you pointed out, the two flows have EXACTLY the same characteristics. So they leave the source at the same time, they take the same amount of time to travel down their respective links, and they arrive at the relay node at the EXACT same time. Problem is, only one packet can actually ride the next link. Yes, they will queue up until the queue is full. Then what? Which one is accepted into queue? Which is dropped? You know that DropTail has no fairness. So it's NOT going to pick the packet from the flow that was dropped last time. It's NOT going to pick one at random. So how will the simulator decide? If you have an array with all the packets and you loop over them, then the first one it comes across gets to join the queue. So which one gets to join the queue is determined by its internal order. Since nothing in the simulation is being changed in your simulation... you can do the same thing 1000 times, and the same thing will happen. So the next time a packet comes along, the same packet will be let through. The only way to change this result is to introduce some randomness to the sending order or to modify the how packets are queued. An even better idea is to prevent packets from being lost in the first place. :) Eduardo J. Ortega wrote: I understand that Droptail knows nothing about fairness. But, on the average, and given the fact that both flows have exactly the same characteristics, shouldn't they experience the same average behaviour? thanks. On Wednesday 07 June 2006 08:35, Tyler Ross wrote: This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one
[ns] [help]how to limit number of hops in ad hoc scene
thx -- USTC Alumni Email System
[ns] TCP configuration: how receiver window is defined
Does ns supports the equation: threshold of sending window= Min[rwnd, cwnd] what are rwnd and cwnd responding to in TCL variables? -- USTC Alumni Email System
[ns] NS-2.29 SIGSEV error using DSR
Dear Sir or Madam: I have found what seems to be a bug in either the simulator itself (core) or in one of its components, namely in the DSR algorithm implementation. The scenario and traffic generator files were created with the CMU tools provided and are attached to this email: scen-3-677-677-test (three-node 677m by 677m scenario), cbr-3-3-200-test (three nodes, maximum of three connections, 200 packets/s). The simulation file, wireless.tcl, is based on Marc Greis' tutorial part IX.2. You will find the error details below. Thank you. Yours sincerely, Francisco -- Versions of OS, NS and add-on components installed: OS: Fedora Core 4, Kernel (i686) 2.6.11 ns: 2.29 otcl: 1.11 tclcl: 1.17 Tcl: 8.49 Tk: 8.49 Steps to reproduce the error: 1) ns wireless.tcl output: num_nodes is set 3 INITIALIZE THE LIST xListHead Loading connection pattern... Loading scenario file... Starting Simulation... channel.cc:sendUp - Calc highestAntennaZ_ and distCST_ highestAntennaZ_ = 1.5, distCST_ = 550.0 SORTING LISTS ...DONE! Segmentation fault 2) gdb backtrace; NOTE CAREFULLY that the packet instance address is 0x32, which is clearly invalid! output: Starting program: /usr/local/bin/ns wireless.tcl Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x933000 num_nodes is set 3 INITIALIZE THE LIST xListHead Loading connection pattern... Loading scenario file... Starting Simulation... channel.cc:sendUp - Calc highestAntennaZ_ and distCST_ highestAntennaZ_ = 1.5, distCST_ = 550.0 SORTING LISTS ...DONE! Program received signal SIGSEGV, Segmentation fault. 0x0805a354 in Packet::access (this=0x32, off=3464) at ./common/packet.h:367 367 return (bits_[off]); (gdb) bt #0 0x0805a354 in Packet::access (this=0x32, off=3464) at ./common/packet.h:367 #1 0x0805cb65 in hdr_cmn::access (p=0x32) at ./common/packet.h:495 #2 0x08139c67 in CMUPriQueue::prq_get_nexthop (this=0x9e868e0, id=2) at queue/dsr-priqueue.cc:208 #3 0x0815caba in DSRAgent::xmitFailed (this=0x9d45010, pkt=0xa052330, reason=0x8298d8e DROP_RTR_MAC_CALLBACK) at dsr/dsragent.cc:2695 #4 0x0815d470 in DSRAgent::xmitFlowFailed (this=0x9d45010, pkt=0xa052330, reason=0x8298d8e DROP_RTR_MAC_CALLBACK) at dsr/dsragent.cc:2597 #5 0x0815d4bf in XmitFlowFailureCallback (pkt=0xa052330, data=0x9d45010) at dsr/dsragent.cc:2799 #6 0x08133050 in ARPTable::arpresolve (this=0x9e87cf8, dst=2, p=0xa055cb0, ll=0x9e874f0) at mac/arp.cc:164 #7 0x08118765 in LL::sendDown (this=0x9e874f0, p=0xa055cb0) at mac/ll.cc:203 #8 0x0811855c in LL::recv (this=0x9e874f0, p=0xa055cb0) at mac/ll.cc:163 #9 0x080e398c in LL::handle (this=0x9e874f0, e=0xa055cb0) at ./mac/ll.h:85 #10 0x08051ebb in Scheduler::dispatch (this=0x9a3b7e8, p=0xa055cb0, t=55.275470096642685) at common/scheduler.cc:150 #11 0x08051ee6 in Scheduler::run (this=0x9a3b7e8) at common/scheduler.cc:129 #12 0x080520de in Scheduler::command (this=0x9a3b7e8, argc=2, argv=0xbf9a2af0) at common/scheduler.cc:198 #13 0x0826364a in TclClass::dispatch_cmd (clientData=0x9a3b7e8, argc=5, argv=0xbf9a2ae4) at Tcl.cc:490 #14 0x082672d6 in OTclDispatch (cd=Variable cd is not available. ) at otcl.c:434 ---Type return to continue, or q return to quit---q Quit 3) valgrind leak-check=full output: ==3320== Memcheck, a memory error detector for x86-linux. ==3320== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==3320== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==3320== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==3320== For more details, rerun with: -v ==3320== num_nodes is set 3 INITIALIZE THE LIST xListHead Loading connection pattern... Loading scenario file... Starting Simulation... channel.cc:sendUp - Calc highestAntennaZ_ and distCST_ highestAntennaZ_ = 1.5, distCST_ = 550.0 SORTING LISTS ...DONE! ==3320== Invalid read of size 4 ==3320==at 0x805A354: Packet::access(int) const (packet.h:367) ==3320==by 0x805CB64: hdr_cmn::access(Packet const*) (packet.h:495) ==3320==by 0x8139C66: CMUPriQueue::prq_get_nexthop(int) (dsr-priqueue.cc:208) ==3320==by 0x815CAB9: DSRAgent::xmitFailed(Packet*, char const*) (dsragent.cc:2695) ==3320==by 0x815D46F: DSRAgent::xmitFlowFailed(Packet*, char const*) (dsragent.cc:2597) ==3320==by 0x815D4BE: XmitFlowFailureCallback(Packet*, void*) (dsragent.cc:2799) ==3320==by 0x813304F: ARPTable::arpresolve(int, Packet*, LL*) (arp.cc:164) ==3320==by 0x8118764: LL::sendDown(Packet*) (ll.cc:203) ==3320==by 0x811855B: LL::recv(Packet*, Handler*) (ll.cc:163) ==3320==by 0x80E398B: LL::handle(Event*) (ll.h:85) ==3320==by 0x8051EBA: Scheduler::dispatch(Event*, double) (scheduler.cc:150)==3320==by 0x8051EE5: Scheduler::run() (scheduler.cc:129) ==3320== Address 0x4E is not stack'd, malloc'd or (recently) free'd ==3320== ==3320==
[ns] ns-2 DdoS package
Hi, I am a new user of ns-2, and i need to simulate a DDoS attack. Is there any existing package that i can use? Thank you in advance -- -- ~~ Ahmad Fadlallah Elève chercheur (PHD Student) Ecole Nationale Supérieure des Télécommunications, GET - CNRS UMR 5141 - LTCI Département INFRES Tel: + 33 1 45 81 77 27, Fax : + 33 1 45 81 31 19 E-Mail : [EMAIL PROTECTED] ~~
Re: [ns] help MPEG4 traffic!!!
On 6/9/06, Cristina Marisol Ortiz De La Roche [EMAIL PROTECTED] wrote: Hi everyone!!! I'm trying simulate MPEG4 traffic with the file MPEG4_traffic.cc from Ashraf Matrawy (page http://www.sce.carleton.ca/~amatrawy/mpeg4/). I have done everything that was in the readme file, but when i simulate the traffic, ns-2 doesn't find the file. The error is: invalid command name Application/Traffic/MPEG4. I dont't know if i'm doing something wrong with the makefile (because i am not an expert). Someone has already work with this file??? Thanks a lot for a helpful information Best regards, Cristina Hi, i'm currently using this MPEG4 traffic source without any problem. You have to put mpeg4_traffic.cc in ns-allinone-2.29/ns-2.29/tools and add the following line in your Makefile that you can find in the ns-allinone-2.29/ns-2.29 directory: tools/mpeg4_traffic.o \ pay attention to the last backslash, it's important and another important thing is put this line under the OBJ_CC. Ok reasuming: - put mpeg4_traffic.cc in the tools directory - edit the Makefile searching for OBJ_CC and adding this line: tools/mpeg4_traffic.o \ - run the command make from the same directory of the Makefile That's it. -- Daniele
Re: [ns] Clearing a queue at a node in ns-2
If you want to stop queueing at all, then in queue.cc, within void Queue::recv(Packet* p, Handler*) method, comment everything else but the line target_-recv(p, qh_); I dont know whether will it answer your problem or not. Shafiq - Original Message - From: [EMAIL PROTECTED] To: Pedro Vale Estrela [EMAIL PROTECTED] Cc: ns-users@ISI.EDU Sent: Friday, June 09, 2006 6:32 PM Subject: Re: [ns] Clearing a queue at a node in ns-2 Whoah, that is too complicated for me. I don't know ns-2 very well. What do you mean by: make a pointer to the ITF -- doesn't it have a pointer (uptarget_)? According to the diagram on pg 145 I should do uptarget_ -downtarget_-reset() since uptarget will take me to the LL, downtarget will take me to the IFq, and reset will reset the queue for that node. But this doesn't work. Uptarget_ gives me an NsObject instead of a LL object... On Fri, 9 Jun 2006, Pedro Vale Estrela wrote: Yes, http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf pag 145, - at your C++ MAC module, make a pointer to the ITF; - either search the C++ NODE methods for getting the pointer reference you need (you want the reverse of the downtarget_ on the ITF; for making this, search the code that sets the downtarget_ variable in C++ in the ITF; (tip: use DDD, put a breakpoint somewhere in mobilenode.cc) in that moment, set something like: downtarget_-my_ITF_ = this; - then at the appropriate time, call reset() of it. my_ITF-reset(); Of course that this is not good C++ Object-Orientation practices, but use it to simply try your ideia; if it works nice, then make the same thing with provte variables and public set/get methods. You can also perform the same trick by: Calling TCL / searching the ITF object you want based on the current MAC object / call reset of it. The benefit is that you can fine tune this method without recompiling NS2 each time. If this works, please put this on the NS2 WIKI! Pedro Vale Estrela Hi ns, I'd like to clear a node's queue from the mac-layer in my simulation after I've received a certain packet. Can I call a PacketQueue function like reset() from the mac layer? If not, how would I clear the queue? Thanks! Kathy
Re: [ns] Clearing a queue at a node in ns-2
...I'd even be willing to just make the queue blocked at the node, but I can't seem to access the blocked_ variable from mac-802_11.cc (which is where I need to have this queue stuff happen). Can anyone help? Kathy On Fri, 9 Jun 2006, Shafiq Hashmi wrote: If you want to stop queueing at all, then in queue.cc, within void Queue::recv(Packet* p, Handler*) method, comment everything else but the line target_-recv(p, qh_); I dont know whether will it answer your problem or not. Shafiq - Original Message - From: [EMAIL PROTECTED] To: Pedro Vale Estrela [EMAIL PROTECTED] Cc: ns-users@ISI.EDU Sent: Friday, June 09, 2006 6:32 PM Subject: Re: [ns] Clearing a queue at a node in ns-2 Whoah, that is too complicated for me. I don't know ns-2 very well. What do you mean by: make a pointer to the ITF -- doesn't it have a pointer (uptarget_)? According to the diagram on pg 145 I should do uptarget_ -downtarget_-reset() since uptarget will take me to the LL, downtarget will take me to the IFq, and reset will reset the queue for that node. But this doesn't work. Uptarget_ gives me an NsObject instead of a LL object... On Fri, 9 Jun 2006, Pedro Vale Estrela wrote: Yes, http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf pag 145, - at your C++ MAC module, make a pointer to the ITF; - either search the C++ NODE methods for getting the pointer reference you need (you want the reverse of the downtarget_ on the ITF; for making this, search the code that sets the downtarget_ variable in C++ in the ITF; (tip: use DDD, put a breakpoint somewhere in mobilenode.cc) in that moment, set something like: downtarget_-my_ITF_ = this; - then at the appropriate time, call reset() of it. my_ITF-reset(); Of course that this is not good C++ Object-Orientation practices, but use it to simply try your ideia; if it works nice, then make the same thing with provte variables and public set/get methods. You can also perform the same trick by: Calling TCL / searching the ITF object you want based on the current MAC object / call reset of it. The benefit is that you can fine tune this method without recompiling NS2 each time. If this works, please put this on the NS2 WIKI! Pedro Vale Estrela Hi ns, I'd like to clear a node's queue from the mac-layer in my simulation after I've received a certain packet. Can I call a PacketQueue function like reset() from the mac layer? If not, how would I clear the queue? Thanks! Kathy
