Re: [ns] Can NS-2 be used to transmit real video sequences?(galaxy-huang)
You could also have a look at http://www.item.ntnu.no/~arnelie/Evalvid-RA.htm ... :-) - Arne - Original Message - From: "Imad Abdeljaouad" To: Sent: Tuesday, May 05, 2009 4:18 PM Subject: Re: [ns] Can NS-2 be used to transmit real video sequences?(galaxy-huang) > > google Evalvid there is a link in the website about video and ns2! > >> >> 3. Can NS-2 be used to transmit real video sequences? (galaxy-huang) >> >> Message: 3 >> Date: Mon, 4 May 2009 10:25:44 +0800 (CST) >> From: galaxy-huang >> Subject: [ns] Can NS-2 be used to transmit real video sequences? >> To: ns-users >> Message-ID: >> >> <25628181.351191241403944698.javamail.corem...@bj163app121.163.com> >> Content-Type: text/plain; charset=gbk >> >> hi everyone >> Recently,i am reading one book about streaming over the wireless >> network,today i come across such a sentence:"as well as using real video >> sequences and transmitting them using an NS-2 simulator-based >> implementation >> of the 802.11a/b/g MAC standard." >> My question is:can NS-2 be used to transmit real video sequences and ,if >> can, how to achieve this purpose?Could someone tells me about this and >> recommends me some book or website to refer to? >> Thanks in advance! >> Guisong Huang >> >> >
Re: [ns] sample code for wsn
Hi,
You should inspect the source file and clean it up for line breaks where it
should not be. It is easy, jusr 2-3 places. Split into separate wsn1.scn
file where that information is given. When done, the code works perfectly.
- Arne
- Original Message -
From: "Habeshawit2God"
To:
Sent: Tuesday, March 17, 2009 6:27 PM
Subject: Re: [ns] sample code for wsn
>
>
> Dear naveen prabu,
>
> As per your advise i tried it however it doesn't work and here is the
> error
> message it came up with i went to the line it is referring to and realize
> that there is actually something wrong with it. Here is the error
> message:
>
> siu06...@sie59a:~/Documents$ ns wsn1.tcl
> bad option "file": must be add, info, remove, variable, vdelete, or vinfo
>while executing
> "trace file for wpan (special handling needed)"
>(file "wsn1.tcl" line 47)
>
>
> Dear nabeen, hoping to hear from you soon, i would like to thank you very
> much in advance.
>
> Best regards,
>
> Habeshawit2God
>
> P.S please do not hesitate to drop me an e-mail using my personal e-mail
> and
> I would also appreciate it if you can give me reply between today and
> tomorrow as i have to hand in my project on Thursday 19thMarch 2009!!
>
>
> naveen prabu wrote:
>>
>>
>> I have pasted sample tcl file and scenario file here...
>> save scn file as wsn1.scn and tcl file as (say)wsn1.tcl and run tcl
>> file...
>>
>> try runnin thisif any bugs then let me know...
>>
>> wsn1.tcl
>>
>>
>> # ==
>> # Define options
>> # ==
>> set val(chan) Channel/WirelessChannel;# Channel Type
>> set val(prop) Propagation/TwoRayGround ;# radio-propagation
>> model
>> set val(netif) Phy/WirelessPhy/802_15_4
>> set val(mac)Mac/802_15_4
>> set val(ifq)Queue/DropTail/PriQueue;# interface queue
>> type
>> set val(ll) LL ;# link layer type
>> set val(ant)Antenna/OmniAntenna;# antenna model
>> set val(ifqlen) 50 ;# max packet in ifq
>> set val(nn) 25 ;# number of
>> mobilenodes
>> set val(rp) AODV ;# routing protocol
>> set val(x) 50
>> set val(y) 50
>>
>> set val(nam) wsn1.nam
>> set val(traffic) ftp;# cbr/poisson/ftp
>>
>> #read command line arguments
>> proc getCmdArgu {argc argv} {
>> global val
>> for {set i 0} {$i < $argc} {incr i} {
>> set arg [lindex $argv $i]
>> if {[string range $arg 0 0] != "-"} continue
>> set name [string range $arg 1 end]
>> set val($name) [lindex $argv [expr $i+1]]
>> }
>> }
>> getCmdArgu $argc $argv
>>
>> set appTime10.0 ;# in seconds
>> set appTime20.3 ;# in seconds
>> set appTime30.7 ;# in seconds
>> set stopTime100 ;# in seconds
>>
>> # Initialize Global Variables
>> set ns_ [new Simulator]
>> set tracefd [open ./wsn1.tr w]
>> $ns_ trace-all $tracefd
>> if { "$val(nam)" == "wsn1.nam" } {
>> set namtrace [open ./$val(nam) w]
>> $ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
>> }
>>
>> $ns_ puts-nam-traceall {# nam4wpan #} ;# inform nam that this is a
>> trace file for wpan (special handling needed)
>>
>> Mac/802_15_4 wpanNam namStatus on ;# default = off (should be turned
>> on before other 'wpanNam' commands can work)
>> #Mac/802_15_4 wpanNam ColFlashClr gold ;# default = gold
>> #Mac/802_15_4 wpanNam NodeFailClr grey ;# default = grey
>>
>>
>> # For model 'TwoRayGround'
>> set dist(5m) 7.69113e-06
>> set dist(9m) 2.37381e-06
>> set dist(10m) 1.92278e-06
>> set dist(11m) 1.58908e-06
>> set dist(12m) 1.33527e-06
>> set dist(13m) 1.13774e-06
>> set dist(14m) 9.81011e-07
>> set dist(15m) 8.54570e-07
>> set dist(16m) 7.51087e-07
>> set dist(20m) 4.80696e-07
>> set dist(25m) 3.07645e-07
>> set dist(30m) 2.13643e-07
>> set dist(35m) 1.56962e-07
>> set dist(40m) 1.20174e-07
>> Phy/WirelessPhy set CSThresh_ $dist(15m)
>> Phy/WirelessPhy set RXThresh_ $dist(15m)
>>
>> # set up topography object
>> set topo [new Topography]
>> $topo load_flatgrid $val(x) $val(y)
>>
>> # Create God
>> set god_ [create-god $val(nn)]
>>
>> set chan_1_ [new $val(chan)]
>>
>> # configure node
>>
>> $ns_ node-config -adhocRouting $val(rp) \
>> -llType $val(ll) \
>> -macType $val(mac) \
>> -ifqType $val(ifq) \
>> -ifqLen $val(ifqlen) \
>> -antType $val(ant) \
>> -propType $val(prop) \
>> -phyType $val(netif) \
>> -topoInstance $topo \
>> -agentTrace OFF \
>> -routerTrace OFF \
>> -macTrace ON \
>> -movementTrace OFF \
>> #-energyModel "EnergyModel" \
>> #-initialEnergy 1 \
>> #-rxPower 0.3 \
>> #-txPower 0.3 \
>> -channel $chan_1_
>>
>> for {set i 0}
[ns] link_->bandwidth() returns ZERO
Hi, I've implemented my own Queue system which worked great under ns-2.28. Now I have moved to ns-2.33 and I notice that I am not longer capable of transfering the link bandwidth correctly from TCL to the C/C++ source running the Queue system. Actually, the link_->bandwidth() call, which should (and used to correctly) return the link bandwidth, now returns zero! Is this a known issue? Or, could I have ported my Queue system incorrectly from ns-2.28? Besides this, the Queuing system works correctly. -Arnie Trondheim, Norway
Re: [ns] Quality of RNGs and PriorityQueue suggestions
Dear Cesar, Thank you so much for pointing me to the work of Martina! This is in fact quite "frightening"! I have to examine my past own work and check to see if this have also influenced my own results. The ns-2 community should be better notified on this matter: although I now see that the ns-manual do cover this issue (but there are no warnings, are there?). best regards Arne Lie SINTEF/NTNU - Original Message - From: "César Cárdenas" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, October 18, 2007 8:51 AM Subject: Quality of RNGs and PriorityQueue suggestions Dear Arne, Take a look at the work from Martina Umlauft: http://wit.tuwien.ac.at/people/umlauft/index.html#publications Also, review the related chapter on ns-manual. Dear Hossein, As /salva said: http://mailman.isi.edu/pipermail/ns-users/2007-October/061415.html Please, read the following documents: Peter Pieda, Jeremy Ethridge, Mandeep Baines, and Farhan Shallwani. A Network Simulator, Differentiated Services Implementation. Open IP, Nortel Networks, 2000. The related chapter on ns-manual and n3 from Altman and Jimenez: http://www-sop.inria.fr/maestro/personnel/Eitan.Altman/COURS-NS/n3.pdf Then configure Diffserv module with 2 physical queues with 1 virtual queue and Droptail instead of RED as well as PRI scheduling...Priority can be strict or rated... Good luck, Cesar César Cárdenas-Pérez ([EMAIL PROTECTED]) Monterrey Tech, Querétaro Campus, México http://www.qro.itesm.mx Personal Phone: +(33) 633306689 Office Phone: +(33) 145817146 Office Fax: +(33) 145813119 Skype pseudo: cesarcardenas7 All phones and fax from abroad France The content of this data transmission is not considered as an offer, proposal, understanding, or agreement unless it is confirmed in a document signed by a legal representative of ITESM. The content of this data transmission is confidential and it is intended to be delivered only to the addresses, therefore, it shall not be distributed and/or disclosed through any mean without the original sender's previous authorization. If you are not the addressee you are forbidden to use it, either totally or partially, for any purpose.
[ns] Ns-2 and quality of Pseudo Random Number Generation
Hi, When I started to use ns-2 three years ago "I heard" that the pseudo random generators of ns-2 PRNG were of high quality (rng.cc). However, after reading "On Shortcomings of the ns-2 Random Number Generator" by Bernhard Hechenleitner et al. from 2002, I wonder if the limitations highlighted by that paper have been fixed in the years after? In short, the paper states that if you select bad seeds, your rng generated data will be based on highly correlated sources (whatever you use the PRNG for). The highly superior Mersenne Twister method is cited and tested for comparison. When I look into the ns-2 CVS, and open the latest rng.cc, I find the very exact lines of code and comments as indicated by Hechenleiter, so I worry that one can still "select bad seeds"? I hope somebody can throw some light into this issue. best regards Arne Lie
Re: [ns] TCP and packet drop: where are the retransmitted packets?
Well, I assume that cong_action is Congestion Action, and dropped packets are mainly caused by congestion, which leads to retransmission. So this makes sense. Thanks Amit! - Arne _ Fra: Amit Mondal [mailto:[EMAIL PROTECTED] Sendt: 28. juni 2006 00:13 Til: Arne Lie Emne: Re: [ns] TCP and packet drop: where are the retransmitted packets? Hi Arne, Are u sure ns-2 mark "A" flag only for retransmitted packet. In the trace.cc file it says cong_action only, not retransmitted packet. Rgds -Amit On 6/27/06, Arne Lie <[EMAIL PROTECTED]> wrote: Actually; I just discovered that the retransmitted packets ARE there in the trace file. The TCP sequence number (column two from the right) is used as it should, in addition an "A" flag is used to mark a retransmitted packet. Something went wrong with my first search on this topic. Again, ns-2 is my best friend, and thanks to Phil and Ethan for their time. - Arne > -Opprinnelig melding- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne > av Phil Miller > Sendt: 27. juni 2006 14:30 > Til: Arne Lie > Kopi: ns-users@isi.edu > Emne: Re: [ns] TCP and packet drop: where are the > retransmitted packets? > > >From what I've observed, the normal TCP agents don't > actually reliable > send each packet in the stream, they only simulate the flow > and congestion control dynamics that TCP would exhibit, so > that the amount of generated traffic is accurate. Give the > FullTCP agents a try. > > Phil > > On 6/27/06, Arne Lie < [EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > For some time I have only been interested in the congestion > response > > of the different TCP congestion control algorithms, and the way it > > balances flow throughput to available capacity, packet drop > statistics, etc. > > > > However, now I need to see how well TCP tackles > retransmissions, e.g. > > with SACK. When I inspect the event trace file, dropped > packets are "never" > > retransmitted, in that ns-2 seems to increment the sequence numbers > > (both per flow and per simulation) all the time, > > >>>>>>>making it impossible to know WHEN a retransmission > is performed. > > <<<<<<<<< > > > > Is this a correct observation? If yes, are there any > workarounds? If > > incorrect, how *do* I find the retransmission event, and e.g. how > > *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? > > > > best regards > > > > Arne > >
Re: [ns] TCP and packet drop: where are the retransmitted packets?
Actually; I just discovered that the retransmitted packets ARE there in the trace file. The TCP sequence number (column two from the right) is used as it should, in addition an "A" flag is used to mark a retransmitted packet. Something went wrong with my first search on this topic. Again, ns-2 is my best friend, and thanks to Phil and Ethan for their time. - Arne > -Opprinnelig melding- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne > av Phil Miller > Sendt: 27. juni 2006 14:30 > Til: Arne Lie > Kopi: ns-users@isi.edu > Emne: Re: [ns] TCP and packet drop: where are the > retransmitted packets? > > >From what I've observed, the normal TCP agents don't > actually reliable > send each packet in the stream, they only simulate the flow > and congestion control dynamics that TCP would exhibit, so > that the amount of generated traffic is accurate. Give the > FullTCP agents a try. > > Phil > > On 6/27/06, Arne Lie <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > For some time I have only been interested in the congestion > response > > of the different TCP congestion control algorithms, and the way it > > balances flow throughput to available capacity, packet drop > statistics, etc. > > > > However, now I need to see how well TCP tackles > retransmissions, e.g. > > with SACK. When I inspect the event trace file, dropped > packets are "never" > > retransmitted, in that ns-2 seems to increment the sequence numbers > > (both per flow and per simulation) all the time, > > >>>>>>>making it impossible to know WHEN a retransmission > is performed. > > <<<<<<<<< > > > > Is this a correct observation? If yes, are there any > workarounds? If > > incorrect, how *do* I find the retransmission event, and e.g. how > > *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? > > > > best regards > > > > Arne > >
Re: [ns] TCP and packet drop: where are the retransmitted packets?
Phil, Thanks, I will try the FullTCP and see if that helps. But, what kind of TCP CC algorithm is FullTCP using; can I choose between different versions? Arne > -Opprinnelig melding- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne > av Phil Miller > Sendt: 27. juni 2006 14:30 > Til: Arne Lie > Kopi: ns-users@isi.edu > Emne: Re: [ns] TCP and packet drop: where are the > retransmitted packets? > > >From what I've observed, the normal TCP agents don't > actually reliable > send each packet in the stream, they only simulate the flow > and congestion control dynamics that TCP would exhibit, so > that the amount of generated traffic is accurate. Give the > FullTCP agents a try. > > Phil > > On 6/27/06, Arne Lie <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > For some time I have only been interested in the congestion > response > > of the different TCP congestion control algorithms, and the way it > > balances flow throughput to available capacity, packet drop > statistics, etc. > > > > However, now I need to see how well TCP tackles > retransmissions, e.g. > > with SACK. When I inspect the event trace file, dropped > packets are "never" > > retransmitted, in that ns-2 seems to increment the sequence numbers > > (both per flow and per simulation) all the time, > > >>>>>>>making it impossible to know WHEN a retransmission > is performed. > > <<<<<<<<< > > > > Is this a correct observation? If yes, are there any > workarounds? If > > incorrect, how *do* I find the retransmission event, and e.g. how > > *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? > > > > best regards > > > > Arne > >
Re: [ns] TCP and packet drop: where are the retransmitted packets?
Ethan, Thanks, I will have a look and see if full TCP header is possible; however, I need only a unique sequence number series. Arne > -Opprinnelig melding- > Fra: Ethan Giordano [mailto:[EMAIL PROTECTED] > Sendt: 27. juni 2006 12:49 > Til: Arne Lie > Emne: Re: [ns] TCP and packet drop: where are the > retransmitted packets? > > There are two different sequence numbers...the TCP sequence > number and the internal unique id for each packet. I think > you have to turn on tcp header output for the trace to see > the tcp sequence number. > > ~Ethan > > Arne Lie wrote: > > Hi all, > > > > For some time I have only been interested in the congestion > response > > of the different TCP congestion control algorithms, and the way it > > balances flow throughput to available capacity, packet drop > statistics, etc. > > > > However, now I need to see how well TCP tackles > retransmissions, e.g. > > with SACK. When I inspect the event trace file, dropped > packets are "never" > > retransmitted, in that ns-2 seems to increment the sequence numbers > > (both per flow and per simulation) all the time, > > > >>>>>>>> making it impossible to know WHEN a retransmission > is performed. > >>>>>>>> > > <<<<<<<<< > > > > Is this a correct observation? If yes, are there any > workarounds? If > > incorrect, how *do* I find the retransmission event, and e.g. how > > *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? > > > > best regards > > > > Arne > >
[ns] TCP and packet drop: where are the retransmitted packets?
Hi all, For some time I have only been interested in the congestion response of the different TCP congestion control algorithms, and the way it balances flow throughput to available capacity, packet drop statistics, etc. However, now I need to see how well TCP tackles retransmissions, e.g. with SACK. When I inspect the event trace file, dropped packets are "never" retransmitted, in that ns-2 seems to increment the sequence numbers (both per flow and per simulation) all the time, >>>making it impossible to know WHEN a retransmission is performed. < Is this a correct observation? If yes, are there any workarounds? If incorrect, how *do* I find the retransmission event, and e.g. how *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? best regards Arne
Re: [ns] Memory leak in TFRC?!
Daniel, Thanks, I will check it out! Arne On Thu, March 16, 2006 3:47 pm, Daniel Mahrenholz wrote: > On Thursday 16 March 2006 15:01, Arne Lie wrote: >> In my work of enabling a VBR video application on top of TFRC in >> ns-2.28, >> I observe that I have gotten a memory leak, which is difficult to trace! >> Two questions: >> >> 1. Anybody having suggestions in how to track this down? (gdb, >> profiling?) > > For memory leaks I recomment to use valgrind - it helped a lot in our > projects. And yes - it is possible to valgrind ns-2 although it is not > that > funny. You will need a lot of memory ... good luck. > > Daniel. > -- > Dipl.-Inf. Daniel Mahrenholz, University of Magdeburg, Germany > Homepage: http://ivs.cs.uni-magdeburg.de/~mahrenho > > >
[ns] Memory leak in TFRC?!
Hi, In my work of enabling a VBR video application on top of TFRC in ns-2.28, I observe that I have gotten a memory leak, which is difficult to trace! Two questions: 1. Anybody having suggestions in how to track this down? (gdb, profiling?) 2. Is it so that ns-2 do dynamic memory allocation for every tiny packet sent? Arne NTNU/Norway
