From Varnit Suri" hello all i just made some very minor changes in dsdv.cc, namely, i defined TRIGGER_UPDATE_ON_FRESH_SEQNUM to implement dsdv-sq, and ran make again. i got a whole lot of errors, some problem in packet.h syntax. i have tried make depend, clean, and make. before this, i never made any changes to the ns code, and i did not touch packet.h at all ( i have not defined new packets either) can any one please help ? dsr/hdr_sr.h: In function `static struct hdr_sr * hdr_sr::access(const class Packet *)' : In file included from packet.h:18, from ttl.cc:8: dsr/hdr_sr.h:69: no matching function for call to `Packet::access (int &) const' packet.h: At top level: In file included from ttl.cc:8: packet.h:159: stray '\' in program packet.h:160: stray '\' in program packet.h:161: stray '\' in program packet.h:162: stray '\' in program packet.h:163: stray '\' in program packet.h:164: stray '\' in program packet.h:175: syntax error before `==' packet.h:175: stray '\' in program packet.h:176: stray '\' in program packet.h:177: stray '\' in program packet.h:178: stray '\' in program packet.h:179: stray '\' in program packet.h:194: `PacketData' was not declared in this scope packet.h:194: `d' was not declared in this scope packet.h:194: warning: ANSI C++ forbids declaration `PacketData' with no typ packet.h:194: syntax error before `:' packet.h:198: `data_' was not declared in this scope packet.h:198: `d' was not declared in this scope packet.h:199: parse error before `}' packet.h:202: destructors must be member functions packet.h:202: virtual outside class declaration packet.h: In function `void PacketData()': packet.h:194: previous non-function declaration `int PacketData' packet.h:202: conflicts with function declaration `void PacketData()' packet.h:203: `data_' undeclared (first use this function) packet.h:203: (Each undeclared identifier is reported only once packet.h:203: for each function it appears in.) Kind Regards Suri From al-shum@eng.uah.edu Sat Feb 1 05:15:45 2003 From: al-shum@eng.uah.edu (Mohammad Al-Shurman) Date: Sat Feb 1 05:15:45 2003 Subject: [ns] mobile node velocity Message-ID: <005901c2c9ac$be5d7930$26ebe592@shurman> This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C2C97A.73A40F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all : i tried to get the mobile node speed using the function getVelo() but i = got strange results during all the simulation the velocity is zero , i = tried to print mobilenode coordinates and i got variable cordinates = which mean the nodes is moving but why getVelo() is not working??? any comment will be appreciated Mohammad Al-Shurman Computer Engineering Dept. University of Alabama - Huntsville ------=_NextPart_000_0056_01C2C97A.73A40F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi all :
i tried to get the mobile = node speed=20 using the function getVelo() but i got strange results during all the = simulation=20 the velocity is zero , i tried to print mobilenode coordinates and i got = variable cordinates which mean the nodes is moving but why getVelo() is = not=20 working???
any comment will be appreciated
Mohammad Al-Shurman
Computer = Engineering=20 Dept.
University of Alabama - = Huntsville
------=_NextPart_000_0056_01C2C97A.73A40F80-- From rameshr657@yahoo.co.in Sat Feb 1 05:16:26 2003 From: rameshr657@yahoo.co.in (=?iso-8859-1?q?Ramesh=20Rajagopalan?=) Date: Sat Feb 1 05:16:26 2003 Subject: [ns] Malicious node in ns2 - please reply Message-ID: <20030201064136.6119.qmail@web8203.mail.in.yahoo.com> --0-1096017641-1044081696=:1665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi! I want to simulate a network with one of the nodes as malicious. so i need to re configure the node. I am looking at address classifier where it is mentioned that a slot number is got from destination address. I am planning on doing some modifications. May i know which are the files i am alowed to modify? Can i change : /ns/Classifier.cc , /tcl/lib/ns-node.tcl , /ns/routing/rttable.cc . also, the methods rt-delete and rt-add in file rttable.cc are similar to add-route and delte-route in file ns-rtmodule.cc Can some one please tell me what is the difference in the procedures between these files? Also if i want only one of the nodes in the network to use this modified source code, how do i do that? the whole scenario looks complex to me. please help. thanx in advance Ramesh Ramesh Rajagopalan Graduate Student Department of Electrical Engineering Syracuse University New York Ramesh Rajagopalan Graduate Student Department of Electrical Engineering Syracuse University New York Catch all the cricket action. Download Yahoo! Score tracker --0-1096017641-1044081696=:1665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi!

I want to simulate a network with one of the nodes as malicious. so i need to re configure the node. I am looking at address classifier where it is mentioned that a slot number is got from destination address. I am planning on doing some modifications. May i know which are the files i am alowed to modify? Can i change : /ns/Classifier.cc , /tcl/lib/ns-node.tcl ,  /ns/routing/rttable.cc .

also, the methods rt-delete and rt-add in file rttable.cc are similar to add-route and delte-route in file ns-rtmodule.cc

Can some one please tell me what is the difference in the procedures between these files? Also if i want only one of the nodes in the network to use this modified source code, how do i do that? the whole scenario looks complex to me. please help.

thanx in advance

Ramesh



Ramesh Rajagopalan
Graduate Student
Department of Electrical Engineering
Syracuse University
New York

Ramesh Rajagopalan
Graduate Student
Department of Electrical Engineering
Syracuse University
New York

Catch all the cricket action. Download Yahoo! Score tracker --0-1096017641-1044081696=:1665-- From johnh@ISI.EDU Sat Feb 1 05:17:19 2003 From: johnh@ISI.EDU (John Heidemann) Date: Sat Feb 1 05:17:19 2003 Subject: [ns] ns-2 FAQ Message-ID: <200302010909.h1199cE4015177@dash.isi.edu> The Network Simulator ns-2: Frequently Asked Questions (This FAQ is also on the web at http://www.isi.edu/nsnam/ns/ns-faq.html.) * _Where do I get ns?_ From the ns web site at http://www.isi.edu/nsnam/ns/ns.html and the download page http://www.isi.edu/nsnam/ns/ns-tests.html. * _What platforms does ns run on and what kind of hardware do I need?_ Please see "where to start" on the building ns web page: http://www.isi.edu/nsnam/ns/ns-build.html#start. * _What should I do if I have trouble downloading/extracting ns?_ This question is answered in detail at http://www.isi.edu/nsnam/ns/ns-problems.html#downloading. * _What should I do if I encounter problems building ns?_ Check: 1. the README that comes in the distribution (very brief), 2. the "installation problems, bug fixes and help" web page http://www.isi.edu/nsnam/ns/ns-problems.html, 3. the archives of the ns-users mailing list http://www.isi.edu/nsnam/ns/ns-lists.html, 4. post a bug report (see below) http://www.isi.edu/cgi-bin/nsnam/reportbug.cgi. * _What do I do after I successfully build ns?_ + Put the path to your ns executable into your PATH environment + Put the path to your otcl into your LD_LIBRARY_PATH environment + Put the path to your tcl library into your TCL_LIBRARY environment * _Where can I find documentation for ns?_ All documentation is linked from the main ns web page http://www.isi.edu/nsnam/ns/. Documentation includes a tutorial (originally from Marc Greis) and a reference manual (ns notes and documentation). * _Words, words, words... that documentation is nice, but where are some sample scripts I can start from?_ Many sample scripts can be found in the ns distribution in ~ns-2/tcl/ex and ~ns-2/tcl/test. * _What protocols does ns support?_ A lot! Almost all variants of TCP, several forms of multicast, wired networking, several ad hoc routing protocols and propagation models (but not cellular phones), data diffusion, satellite, and other stuff. See the documentation (described above) for details, or download ns and look. * _How do I know that ns correctly implements these protocols?_ Ns has validation tests that cover many protocols, see http://www.isi.edu/nsnam/ns/ns-tests.html. However, ultimately users are responsible for verifying that ns is accurate for their purposes---since we cannot foresee all the ways ns may be used, we cannot test all cases with all inputs. * _Are there any contributed/additional protocols not in the main distribution?_ Yes, please see the contributed code web page http://www.isi.edu/nsnam/ns/ns-contributed.html. The mailing list archives can also be helpful (see below). * _How should I get started doing something (like implementing a new protocol or trying an experiment)?_ We recommend that you look through the tutorial (see documentation, above), then start with an example program that is most similar to yours (in the tutorial, or in tcl/ex or tcl/test in the distribution), and then start changing things. * _What should I do to compile ns to reflect my changes if I've modified some .cc or .h files?_ go to ns directory and run "make" or "make depend; make" * _How do I subscribe to the ns-users mailing list? How do I search old list archives? I can't take any more---how do I get off this list?_ To subscribe or unsubscribe, see http://www.isi.edu/nsnam/ns/ns-lists.html. The list archive is at http://www.isi.edu/nsnam/ns/ns-lists.html. * _What if I have a question that's not answered here?_ If you've checked the installation problems and bug fixes web page (http://www.isi.edu/nsnam/ns/ns-problems.html) and there's no answer to your question, you may want to file a bug report or post a question to the ns-user's mailing list. First, you should check the archive of the list at http://www.isi.edu/nsnam/ns/ns-lists.html. Your question may already be answered there. If not, you can post a bug report using the web form at http://www.isi.edu/cgi-bin/nsnam/reportbug.cgi. If your question is NOT about ns implementation bugs, you may wish to post to the list. First you should subscribe. Subscription instructions are at http://www.isi.edu/nsnam/ns/ns-lists.html. When posting bug reports, please _always_ include information including at least (the bug report form includes spaces for these): + what version of ns you're using, + what operating system you're running on (not just Linux or Solaris, but RedHat version 7.0 or Solaris 2.4---send us the output of "uname -a"), + what specific behavior you see (if ns doesn't compile, what's the specific error; if TCP does something strange, what exactly did it do [send a pointer to a packet trace]), + what behavior you expected to see (if ns doesn't compile this is obvious, but if TCP does something strange, why is it strange, where is the TCP spec violated?), + pointers to your script detailed output files, + a statement that "yes, I've read the FAQ, ns-problems page, and manual and I couldn't find the answer there" (or a statement about why you didn't do that yet :-) A reminder about mailing list etiquette: + Please check the web pages and list archives before posting your question. + Please keep the body of your post to simple ASCII, not HTML. + Please do _not_ send large attachments (if what you have is bigger than a few kilobytes, put it on a web page and send a URL) + Before posting a question like "did people see my post" or "the list seems down", please check the archives (you can answer this question more accurately by checking yourself rather than asking). + Please don't post subscribe/unsubscribe requests directly to the list, use the lists' information page (see the web page mentioned above for details). _________________________________________________________________ From rima.takla@bmbgroup.com Sat Feb 1 05:17:40 2003 From: rima.takla@bmbgroup.com (rima takla) Date: Sat Feb 1 05:17:40 2003 Subject: [ns] xgraph and trace file Message-ID: hello, please i need help regarding xgraph. i have the file out.tr and i wrote the filtre.awk file for filtering the trace file, how can i exceute the awk file so i could exceute xgraph and then get my resulte? thank you. Rima From asa2@cin.ufpe.br Sat Feb 1 05:18:07 2003 From: asa2@cin.ufpe.br (asa2@cin.ufpe.br) Date: Sat Feb 1 05:18:07 2003 Subject: [ns] range of base station In-Reply-To: <20030131211229.57217.qmail@web40601.mail.yahoo.com> References: <20030131211229.57217.qmail@web40601.mail.yahoo.com> Message-ID: <1422.172.17.97.13.1044098668.squirrel@webmail.cin.ufpe.br> Hi Bhaskar, how I find the value referring the amount of meters that I desire? or either if I to want a distance of 200m which the value of Pt _? thank you~ > > > RXThresh_ does not effect the range of your mobile > node. It is the transmit power (pt_) that does. > Following are some values > > Phy/WirelessPhy set Pt_ 8.5872e-4 ;# 40m tx range > Phy/WirelessPhy set Pt_ 7.214e-3 ;# 100m > Phy/WirelessPhy set Pt_ 0.2818 ;# 250m > > If you want to make it operate at 1000m you might need > to set the corresponding value. Thank You. > > Regards, > Bhaskar > > --- Qingjiang Tian wrote: >> >> >> > Hi All, >> > please help me, How can I change the range of base >> station? >> > I want that the range is 1000m, but i tried to >> insert the follwing command in my script: >> > Phy/WirelessPhy set RXThresh_ 1.42681e-12 >> > but the range is still 250m!! >> > I tried to change this value in ns-default.tcl, >> but the range is still 250m!! >> > If I don't resolve this problem, I can't to >> continue my work and I have a deadline very soon. >> > Thank you, Veronica >> yeah, i have the similar problem. in my simulation, >> i try to control the >> transmission range of mobilenode.so if any one can >> figure out how to >> control it, please kindly let us know. >> btw, how can you know the range is still 250m? >> thanks >> > > > ===== > MobNets, > The Mobile Networking group of > WINLAB, > RUTGERS, the st univ of NJ. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com __________________________________________________ Adalton de Sena Almeida Computer Science MSc Student Universidade Federal de Pernambuco Research Interests: Network http://cin.ufpe.br/~asa2 asa2@cin.ufpe.br From asa2@cin.ufpe.br Sat Feb 1 05:18:26 2003 From: asa2@cin.ufpe.br (asa2@cin.ufpe.br) Date: Sat Feb 1 05:18:26 2003 Subject: [ns] How to change tcp packet size dynamically? In-Reply-To: References: Message-ID: <1425.172.17.97.13.1044098930.squirrel@webmail.cin.ufpe.br> Hi, Sangeeta, The NS does not allow to set the size of the package dinamicamente. A set time the size of the package it cannot more being modified during the simulation. OK! > > > > Hi, >   I need to set the packet size dynamically because the packet > size in my simulation varies. To do this, in tcp.cc I set size_ = > wanted_size in sendmsg(int bytes) which in turn sets > hdr_cmn::access(p)->size() to this value. However, in tcp-sink.cc in > recv(), when I check the value of numbytes I do not get wanted_size but > I get 68. How do I reflect the varying packet sizes at the sink? Thank > You for your help, > Sangeeta. >   >   > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* __________________________________________________ Adalton de Sena Almeida Computer Science MSc Student Universidade Federal de Pernambuco Research Interests: Network http://cin.ufpe.br/~asa2 asa2@cin.ufpe.br From muhdkhan@yahoo.com Sat Feb 1 06:20:03 2003 From: muhdkhan@yahoo.com (tahir mahjabeen) Date: Sat Feb 1 06:20:03 2003 Subject: [ns] wireless trace file Message-ID: <20030201141923.70498.qmail@web40903.mail.yahoo.com> --0-1112398238-1044109163=:69821 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hello I am working on sensor networks protocol. I run leach code succuessfully but dont undetstand these files which are generated except trace file. Please give me soem hints for readding these files. I want to simuate sensor network protocols on the basis of energy level. I fu understand any thing please reply. thanx __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --0-1112398238-1044109163=:69821 Content-Type: application/x-zip-compressed; name="leach_sims.zip" Content-Transfer-Encoding: base64 Content-Description: leach_sims.zip Content-Disposition: attachment; filename="leach_sims.zip" UEsDBBQAAAAIAEqxOy5MgsGQ5y4AAN9lAAAKAAAAbXRlLmVuZXJneW2dV5YF tw1E/2cVWoFOMxP735jrVvH5S5KsMJjuJkGEQqLb94/+/PdrZ1Xtdtf49vfd mn/t+6dB6bOtb442v++M9fUOpUO59c1Z7ejnve2zD5QBZc2+5j6399q7f/tC maK0mr2NcfWRvde+C8LyZ4YeWEeL+EYftf2ZDWWe2cdZ6xu7j6H1QTle9OpT L7mfllBaoCkXyvi6vn7bmfrXrV+CUlD0e2tebVW/sPTv5Y2aB/007afm6beP 3j8voZkJIrSmlfDHqFphj7lwxnfHHa2vu0rLaybBBn19nzP1wrnvCOPa9Ov6 6qUtixs19+hmQzMfbttirDg3v7lODx+aGdHG0QO36qyrzZW52uBE69WXzm23 qdW0L5SbT53VRt3B276v8j6zYkytofbqS4sor7tHGNY9OqWlj2h7u4ZJZoR+ r63d15prnCv+mWRGtMviOgwSG04OvVsexlpXh3XGbGOOeyJDZoVkSEc7xas2 W/X3QrMC7mlpYu83qt/3QrPiXlG2mC4W1v1GSCfyqoNkz5KlNSRRJsGLppNt rYtP2vrqzYfYw4pzSqckWW46wRtJGjCjSUxPg4P6517m0ohiSGRra0c6YLE5 4jIiE/2reVtdL1HfNcms6Bfd4INago4kpPm4NNd3rmRZSiKRMmnlRPTbX63G d+pJ+ggrtJmrX/j2Kr3AZzUsFHvAdKnClYrUzZcsFFJJybqEZjexVrpgUv2+ JCmSAH636xDNpBmxQMW+hqhdrb35U7NlEWKcRALhRbe99Gle7C3W6TzWuFMn +eWFMRNa+Z5zyZAMCWLEYpoXVxLZv3N2n0MnWl78hBd9drT90ymLufUWCCva lV7fvY5WLh7Fhs0TrdLGJOVX59z2LEvZvD+JnjryOpy8aCaZF7Ic0psjbkgG pwyUF7jMDJ1v3yVFXEtS+x3veEUwzv2WjlZ6fWTNhvm0YjKlOiXrOmXQxJZQ Rjass2f1vUtofpYx1uKMMyRrekZCq92bFGtxSgc1dBofRjCL2L9zPNoUdqR/ a+dTlgttZYsNrV0kvbzhZV5MpELn0Qtb8ezSqpyVtPHcLYmSFda/QNqRC8mX RIKF6+nmRexYi3vgG/asdPw9D8VaSNtkuscn2ZConZDMigkXUBytXyobTxAN kUrJoIpNkt/+7MiO/9CGJeZb6+S14d82K/YU+5BZqTfiYVbsZzdlO67WPNHl mPX97Ka+faRB7Q6xMsK040L0SDtHoiwRLTlASOd7ilVaogRaYipNCSlSod+H s7BDIn1ssk6kQpvCzcoIXtQgT9mFbJ2tjkVrrHNHjPSJ4exXYiGXLddYeoU3 fGI4pYhzf/K9Mp6yUt7w2VYeqcKQjZMR1kq3d3XOO8UPAZNdL+3i5iHbTUme aDqJObvYn5WbFWfJcnNaXZYi7LtmhAw2PkDvGguj4GeuGaE3IUvatL6ld4Zk RkidtR2dX3s+06Tx5BldmrILA2Ocb5kTx2coXynL344MtknrCeCeEswpjZMy tnwrsEJ7nPZIfl8gwoUVHZtdMLGjxu9TwRVDp7HEBgmTrOOw7tx67xN20VEN LKE8GqR6UiH2NHFbD5wVhFDPnerj+ol8kvbWtt9X8SESPFmxJpigv61joajY TeloSc5kReQWTo6qzIv5aWEdGFNI2TIHK7yQgMlDNLlFIaNvmRdlXnRZOLlh aY4s3u8hS4WB1G6YW4nniGhWNKQBEMQIKXlDWUyCF9IZLU0GXEogPCL80B/M HPqCvPLRYvoHPoJiTqAVS3ZWzkfsaKHAiKbv14dTlvBueTsI1o0m17JhjsCn rIsJMEEebeGydUpD35gdwkMU+sgn3nVMO7ChB2TqHbIBWy+EPwK1EB4DpOVX Dl77QQO9rjgOCYGkSn9J0DcC1IMxm4R+A7UQHz3uhTXvH+uEARAinfpT6LP/ IKY/JGHQH1Ng5D1lDohQsu4LDyxzmYdggYyWDLkcysDNZNVBmF1mBN+l8xEm EztMgglirgyo9qoNyKPlBCIF0p2S4mqrsq97hGSNEIgfEh+AgeRjm6PBl3KC ciZSGWk0MCiLi3EQoPt0QJIQmUyZPB9p5EAISAIsMZCv0+pCat6shFdooQkZ yrJdvy8Ac1wAkHyJEWvYEHx5MPrim5wQLv6E5IDjYiK1SCGGiZ8yZeXIuw28 OHHuO3KjyyadByEuPSagvUI5kVJ9AmAiEKzXhq0Gl5JDKf7i4PX4Y17AJbZO 5yR3ZUyVkzW4lFuqpk2KrK/1R4k+yKbLLkn7ZARkgyyqI+IgZ6ZvFdGBXIq3 FHC5CvSNVS5xXadoUoykXJY2NGQOPxtzk6wVGDWCOWIOIf8vT5kTW4IndVBg dk6rlkUcr1zn0zC7Yi5RmykBEZ8UQuYYWCpLM3wYAZeSoQ7G12Zl+r4cbsAl buoqMgS4a/NnmmSJkK5I9pec/iAisqwYW4rfn/es0wUeeXkztkGYHPQDVpFV jm2wQBA46Ljx+orzvrwNPkw2g/tRJHURUFNgg94s7deLZAcB2flOMLbiW/34 YAClvll1go0WvFT4rf1WHYitkEz2Vu9sWNzy64wq9csXkRSzFYp/OaSAyiVv iPxr3XLsMuEmxUBy6HKaWjshh9ewEoBKbiQuXSZNxvCG8mINoS+hW6kL53uz BuuFJE4G4CNqlBZEl4IpdXxCk3qX7PRspAL6w5T9d0TSMvn995D5INN9OAJJ ySCMNiVeooFbxVx8c48CBlHOD0uvuB1YcXvkzpBS0nFh6pGNFwO/PBTzQCzZ AUQkGUAI/SFKBTnSS1kiAbIBcjTFfLAZlHkCYAPN81CchSyW1qjtIEOyEyZZ LcApEtVFgkGLzPvCB6mMPHdXuCoPfHzqAZT69JIL2V0r+GSN8pAZIWSsB+SD dcQ6dSv0eYxYBEgHcbHtNSkGQsvlbUOaBlIxJfLQSWEoqia2JuDqD00iCNqv eC0bQXBnSsykIk55voZciIWW/YBJntAhCZwIx0j+zAaDSZ2MPrBhjiRwRv0C Jq0rAL+NPWrRZoNJGfHehcPJGskmRvAMJuXbJKzSgGV0Mny0QZMKlrt+UjJD +M1utgZNSoZwpPoNJ3oiEEGTWtkCg0st0ZmobdCkzNdHzCK/JLkUMjLJnBgF cBXGEyTbj68Gk1Ik+WWxTbaL0CVIIOhB5ksHOEDignn5EIyQDIE+dYBNNmC+ JVgeyFkhzIIIpFPiMAIlpd1TirewLTL/MeP1BEKWQchK2yrO1i+sOE7Fcx+R tJSHzIkpFggwFeo3JSg6FitnRTGwTzKIHUxJNqf/gOTdztqAI2VS3jNmA0kh hzeCC2Kxj7YepLZDRSRlot6pB0dK+aQYcoByDgPAa1IUQz5G6IX81MLRWfaM IxX7y7DLXZDfkqP5Gw9GCnjqbLVGgcIBwoBicVDcSqgsJ9eRVq17BEaiLQhs J3WxZjchRrI5WakzcswxIcACpB6jAOD5FANtCEHShTsQcJGKTcJRKBYEndq3 CLo6edE+IAQ4OHWzQEEEXs178fYJ/oiIsAkAD3/fuzc+u1gaWQ4CivGDkQJ9 KI9OXIhWUuIFBEbikEUQqzt5xBWSOdBwGx/noFMQYDYFFhDbi8+XdUwnW8YP R9ooEot01lEni3AeZpAY1gMy1bJ0n9kTIKmYiri5Y9/XI1gbCPC2BOcgkXIn pgQ0CJpcRHocDE1Y2p6bIJjU4QknOpgdPxQJupDVFElaBn43CTaA0GSDhCRJ WutrpsQqICNCdToEAePlg+jPS2ivuCi/tHkJBpHSYB0MuaPjJUSoYhNkmYpU GtaGCHg8ECnYKJMP2vvYTngaEIneSBVlZqVyAu95HWyYCDsJDgU1OpGbh8yF T8f94Udl7XUSXpwxpL7jVVxSzNWz1dF+cirXgJg0TLj3agxJxkWRo0xfH9gs E5KHImiRJZM+AD+Xz8gQUgKs/5QtmLz0exQrhBRNS7sLN3tB2yaZDU4FD1KR CjIrmmoEKYgK3BLCJTIl0T1+CJIATThagqCl9f2+9KLsluyGlOMOEo3jhyAl ifp9kCrZtwiDAaSWLaETkuigWBlIU2wZZaZQEr11Of1mShIvcjeFf4JxBLfj AUi7m66tihlFccIU2HBI2ZN4kUbLpudlMEFqrxWIq7IiCy9iivGCvKNUZU/8 cZPCmHJ9QouEDNLFpiI/Dz8Wtpq8MvBJphiS8aP0wYGyEKa+L4tiysvQyizo +CTCMuDyPCbFMgokgj8Gpv2LDBs/apcHRFWLpK48pSkzJ36IF/Tgwh9PL9z4 keywvP8kXGsEwaY8/yB0hGXUArfsbpbncOIqFu7aaSFZPUcU/DhJJytsIVqW w4sVtkrgVzfFItYXpgY+bnJPt5Hy0wFJ/02KXUCP5NyPZEfo13sNfAR5XDIn Y1NluXnIskAsJrcu+CRUoj2bkiScdkTZQPpFYjEMD3zUmSIi0gx0+fe+5KnB VNJLnJ60OSt/BnIQDUqSJbQylKbEQApvyucKKi9Mzdtu/IR8kZRlgAaFq0wJ fLQSCdbJdJIrie0MfDRkQrwB5qA1kyIP4ZHErrCtJsCHSfyhRZO/0d9u3had wBM7WNXZVXzoiYEEa+E7hBju00qjR2J2QpxauOuWVds+KjzEUYunTTZFLDIJ LiAj+on+IOO84pINHsUrGYqBBSB9eeJfHVM1SmIbICo+3SCC+yo4yzlUbEpF uoMcSZMBHuWAZSC+SHeQI6BW4lVEsjr+br4ZOUp7ceOKB/TE2JEFI8eO9pBz p3x5qD6MH3IU4vhIDJPNFXe9ISNH8UZGjKMRHJadyjOJqCi+OFbQIfQw28Cx UVjtVAgvub5jxgU3Lh2K5IMsqva84lkqKiHgJYVopOrJTpsSwHCdE9LhDGCO NxTcKJNBdocUqV6WZRs36r9JSgwSkHiXoBlLwuXDtk+CTidIIriREowOiFie smJkMbhRFlbmTqctGWroqEnJxU4kS8JiA/VbOHyQaxVrtDgZuw3a/JsPOGpJ MnDaljyMhFhcnQGOZIM65ynTLc0YJsAEWWujTRaizYXwjOOQC0XqFUETo87g xvuRLj2OLpZM4IaQUAprOueQ6SPxPSeUHendCA0Rt6RUFmE+3LixECSOxT6J qSKfGdzYBl6pNeebyTNA8OadnBbUlQsfxATeYjSha1UyvfKD36QaM3+occN2 fQeX5yS8Sd6/Fkt6TCYHhOyfs/0t8afYLJmh3hUeBzMKMW8+r5BMCiYYbdLy wVhpJDfk0UaZAcGMCoOoWMkzXLDRyJdsFBegBBBDlbveQwEK1LrFg7IJfAcd 1IgJ+dgNvlhYyucZGSAMFsOoV2HOzWyjRu9VsvgBqmUBIwQp0VCw452S4EUK 2aTogvZD4l/AyaVlU5KH7in4kRiSjJrfho3SqEuiZ7gSomdNcapJZ6d1txhn 0nTzwUZkSuckzx+ly45sFSl8UnsgGAbfmhIXqYhUwtmxZPeYPQMmEOIT78n4 yivIOJgSRZCs4c102heZNyWSoFcpbKB6qf95N8aMEiuZA5kcukfEXvMmkFGO DxZQ8gYbRnmsCzoSKQGSwz975NeQcRBvadmCnzLa73wMGeVKKeGLN4LN4l6W kCiKXIwcDOrQcHcmVWQbcyiWS4Y73RaQZqJpxGDgiGRAnswZMtIaQQCrpTsZ HYqNouCtsxP6oDzde5sNghgNl0UeFDtjEOwZSCrKYEvyBilq79WQkVIDtCIz 640aMMoUuj6iYyNPeXzWBoxYUEyvXJQOSvJjShLQk/yHjvNckFI+Yg502lCk qsRE8p7l3RgwztRgi+gc9OeHDBhprUCrJHb0ckQXVizitHWTmTmUK0xwegnU QA1RlkenuvOZZJ+l1QqxO7UxRWrhtOGiVtsb3nIAeHs2FLi46WgpBSpXiKk/ uTZcnKRfeknmtjCXeG2KYbMwpJCTCzbXyfH54KJsuGABoEL2X+LrDwUvXoSd nCIhsOxTSHaOmP3PGTu5/RPOBS/qZYP8Ms04llWTLAidRMhHPY3opZup+yWX PqJZuWanUPJMKvkXpb/EkEQ9zzfYORz0lOwYbli7M+VZRhKQY7kspA2bkuIU TQHTFVY9fMqyZbjIzymCXbKdwn3xNY8PZeOiUJuqTvOXAhepRnTnyxV+rHzJ aFEGC/4s0jAULMw7w0VZdJ30wuXL4I/3NhtGadeWJ+IBkgcmxC5iE8hUSSpP NMhgUesCzGPN11OUYEXKX3jhrUCswSaTYMGZjkipDRL5xA0HKx5CUiJSoDmF 0PnDigfILpQESbvyM8GKZEeFJezpXbE1KVUIY4qtvwbCF0rqUjoY0mhp2xkR +4BFAUHCuEMpUkbYWzJYHC4ITUmW9qSFhhKUIDghOR2kb2pFGA0WSVfIhonj pKr3e8YwgXYN3AOh4XlSH7BY5Wq1JL/L0EasAhbvBDfIdMungu68I4PFQYtI Ea3ScfSE3mBxOBGtlSni+bC4pkQdBkl+duuihwlJOpMXEfST5RSn4jeMFfvZ 7qlCHBc5dVNsFGQPtsy5ZEH6UpXP2D9iW2TrqRFian2qQYpyWQRqtP6xvrho I0VpjqRZsVVL2rL9rSDF5kThXhS9tGnhrvWAogIWErloN0VMPwEDJlkZSY08 M2u+fiJZd9LZ+H+ZVP1GQZj/NDohFIWRYaSr4pv8PBnWSSF+YN/kIGtDiCVY 5KUdIFItNMFqQNpK4qmNFPo9TfH5KzJzAUi+k+6iAYGd67PYGoq24OThrwcm UjrT+2X5SREJ2K4fTCRGodXxCAwqSpY/Xw8mTgmEJBNZAoQ8frF98Jc8nLgo QXDdY/2AIpkueK+FdeJQL85AcZK7k9QOOk5klbIGC8Bh44QyNKUSCZtkeNDQ paGVbHLN5kFw4iFXRBsZbUekGE2yLdBPJOPSbNLGhNXrhxOlr3gDcOn8UEWT 4AORvXv8kDSZXhNsCj7cOBnmDWI3TwMSdfpSNfw5RfYVCkxYtG8dMkQXp/FF nqIEtMF0WlzR7nDHIBHhd/abPEqdHGpAooK/5kgbSEUj6PqBRBn0K9SpLxRI Mt8JC2jgGeQb9RFZEAsuLDjDccoidaSwtiLSKcPRhgew7USJ02wzSpRJk9MG 0YBJSWGsH0zErFE/pZ8IFTXlRc7k+WmBkBFrOZ7ARMr2jU6/JgWWZbb0GCY6 7SKhwXwWsa0pCZ1dfuhuzKCIY0pC5+s2NipJbjQwxRiJXKxk5uvIQxOchTRf OknnKnSvV8pgSWBMsiBs0s4kgBuquixyMyBJDrEd8gub8NmaYpg4yEvpd6Wn hdfOh+wWP2kBlRrZalnQHsqSpaAv45BfwNvX+wxMuDRYSezlE7T+71ECkRpl wEU5YGEuTTFQlNmWnMqRLliaR1KeHy5rAj8WdQezZznJjCAWOVS9lbjKlFTn abMhs0usux4lBlGKcKgYOx8bjhoo0jRury2NVLiZowtQLIcJtFe4RyzWwkBx UpWmS93gUubHlP3OTo6MSjFtgyeSZaC4wCWyFwqbFnjQohCgeDlUGapJ692z MAaKpKvEodcFN8PTHacgisLKTv5Jp+vvGCcOch3yOSW24wf9neBEOlwlhhSQ yWJGIYITZQuaK900rs2wLjjx0FOFigmnKOi1ShonyuJsOjdRo3NjR4wSCeJk 0C8Jfbp1LHA7ZpG+lHaoc3fMjSmxi7RTDGqjxBOKHUyye5Bh1X/rrKUyDa+9 HkokJwcDBN1oHGneqkFicxr/0k5b+IhQYALZG4q7Em7qKN1LMEiUh5VsYRXx nifGxyCR7CgmWdIzadgyd4ISD5mg5W4Sp4BN2dYTih2X3gUaBfNI8kjljU4m HEitmj3GiUWZj+NcLs2/tVkQaOjZNMLTZXVz3MaJ0oVJtXyCaupJaXAiSngx p1J6Gt7z0KvLk0WQGF4sc+x5cKI0R75ZRp0yMQDHJJtGnI8+JZz8OVY2xfrA FMFHlL5sBOPyAxOAQgCXhnZF4owTrW1kxQ69xIpOTLFlpENEBpU+2U7wZord w3Iv9SBQxff6mYokbIpHJEQE5cR3U6wOMjG0EOso5AVpp18PJgrXShuEsxXW DdJzpkQbCjheTmPQRGVKsLJQ9yZ9KgA7aeZZDyfS00lhgnkTEo+hvBaNTr6c WiNAzTwITgQHNmyVRI5mAlMSNBH6dA/B0Jq/LD/GiRTsKOxKhNZxT9N+OFEB ZxvOp13jaQjPLopfDC8UVskPWBXEw+MOv0uzmI5tP5iI6lI3ARQfGmV2YCI4 Qz8a1Fj1G34gqXW3XTCCIDRy/QVbAqZxPvwFeKdnSVECD+oQnn7NbdlQUmwS /FJ4JwxN++Pyt4OPaTk0fiLtXNleQqVFd0dzsbBhOvZDiWQMZBw2eXy6P/NM zIBztrg/av3b3zdIpPuMksS10ADQ9g8k0pyDoCve95DDMAkGiL90JNHXrV+Q ZJsSj0AS6/rQmquCJhkciC3DAzh6RJQ8lBxSUdLTeU3SVnjG/UOJk5o6EYxk bZFy3w8lij8fCKxfl/az2YDEa1knrt9OSphiQyDb2DFTg+4eWmD2g4nk9bAe Yu5yr4Ypbkag5XfTGabQihah/VAiIFVCsdEmnYhUej+USFRK3p52OrqS8oxV YA0QvKSEuRZA734oUcHA+WikprhHt7IpYYEiBQkJkxm0K3hpRolS9YaVpBWD rnwfUFAiqQfHvaSZfhSbgXLLw8BP0CNjQoBy74cOXBxvCSGZEktY3r3CbEV5 o7xog0RQHZk9uq7gdN5moAwAUYjNlA6NQ1k0LKDDR2I9mHOgTu8TDUZkZo1m c5ThPFaPeoLNWdKvNvAIUObLKRMOwFJhe0mOX2eIKOdFnQYjcIgpo9bmwXSi gx5GLN6wuAUiHtAfSgyIF/I0xRBRXlWu8iNmkL8++Q4QkSw31VYmnPqTnLlf lCk8Qx20cMAmPGykwJAKKRMSK1JghCippeWs74EQ0PyzfxAR40yCXg/MTjoT 0nJK2UnwQ/bxguxCsRhcZ2foZdHhifOm2CBQxesumWk/+73NySMpO1MeHfsq 959n0oZAZxnRx7BuWUSNEBdN0vRoCKweWGfKfieH9eo0v2jTJtgasDCZDpJU NAbshw6pQNC+R8Gn5dspLCmC2bR6olFPBrftwKCh9ZBjddt3KLYDtDQdGkrl wBk4MCXRogGCLCQAZEZ1jQzFczfXk39v+x3ATqhEsL4QUUXHY+Vt1gJWuty8 R+NtVm1oOMm/CLLJ3zSqH/lOjOHnQTMqNTrQYYkONARxERLR6UShJw/ZJ1CM IX92qUh/0epAQ7FYJloHTV6jxSAHGg5bNTpYaCWIRBsaki3v7u0lr02UvR80 FLC7DNoM8tcC8WbCeTFzd0OgzoGGhbzN1pBo1UWkBijoFgFDQ0oW7iCmEr1z CoaGzWNjJFQanYo927lozgF10O5S/E78qMWA/O0goqAbvn3+SoAhJ+mMB7lm BWumBBi6tVm2ga4ksqsmuaRAVEoGU3KIHng7BoaybJOY1C3VVMFMsSGQmjea HOjXkjKGYlxIhnC55o8rzbKNC6nMf8JYFOmZdjKrhQsbEwv0bDGVhrP1WRsW 6tAYanW8So9eHkmUVIgi7cuXdKoXEFioKFkLkDlqVFXyGcNCyfqWzDTHO6i+ KS9AGET68n+LBj4vup4qaEWu50p0qEDuHywkbSaj7ykYeuhMMQsYC6SxXkZc sCb6HljI1+lWIHJ3595+sFCaQJKb3K/sUFgQVIjsyYDo7GQk6Uk2CR4c5AD0 rY0WrvPvPFRILR9MULS0yTlCsB7wikuDG9aX3twTWCi9Zf6HZhIC2elXOVam j5wCG5OQ0oYNAViIDkp5SARq1XKU58HC7WkwWVNPMR9/28d/PD9Bd9umoMLP owBmRaO0abcLIYf/0dJEfyVTpMOLtQUg9GNSoBjdvP60QaFn3CaFepIz4psp Lzb8SG9dWiBo8TUlgJgBtgW+49hunhnon8D5pmV7kCyRSzsPE9pwysyALphy 84oNCTdi6rqQS0SPksQxTdQKL/gU5aSQjAVo/8QMSj4/wm5Tki9SQFv0ETud VVlCagj0KzCcIaSAxfdBRvx5S1FuJTDKSRoRske5VFn74U6ZMsWegGE0pvgY qHc67fwQId1xMt2UzTdZcVNgwqGXY5J0Je3NKNH5QULmN+lIAkrJF2VthoTk VAsMzlD6CEsDCV3ClfCRuib/Ywo8uEyNyZRQeSIBZb4FEl7PmArWYIjQmWNI qJMbyA4smh7gNiFQgNKoQBVOHFU3JWIgn0vJnkkmZ7DPg4RdAKG2x/E+Cuc+ nkBCST6DV5uYedCLc36QsFMKkLkfmBrgw3mQEEwjcQMTcuLNbDMk1I8M4j9g 3/c0LZCQbAPsJpxwuH9+kLDRk+VWpu08KpRAwjtwBITVZKDkjExqXoLWis52 fZHKgClmQmMuk/lX6ajr5edBQiF5pzPdBUsfuinOkxxCpA5bmeqIjBoS0p8s h1ZUhJEiE5wmqSVcaVMM/vHxGBJuEi6NYW1KmsyFnwcJFbFKFelQpiPpt7JA QiJKRIB7AWg4hWRIeEjEOpVFe6y8rCmuq2qji/QgWkmUaIoNIUmASyBBKT8/ d6LoUAwibyDdbrjP8wOE6MhgClTH+ZEYPA8Qbk9IHlJ2nwDl8HYCCOmdpNlj kEV6imBEeNzRPLTJ8oh23mZMKBPMAICMBQMwMaArtRRGPOmvxoi/3WwbA3KV jULwifsyxcag0eVLGxW9miCF84OFDQxbBE6kdKfPLbDQRf/0wjeAmynWhOlo d1MlZ6LU+wkstONsDhxoo/EZBBYWULIQuQuaDSUGkbwXB3Q40mMe7BhEpm5o K780psVXGBW6r2iRvZD/2YyJnB8qRKYECelbrR2rd154yHUMKNwWmI23CCik PeYjZYc/bGGoQSEhOj0OOBEgdT7jCNkjQx6f/LCzltCAQjGYUY5OJqrvLNqg EKvSM7/OFFKWlmIiM+ZUqxZ9uZEpg0Iqe+A7oiyiShMsBIaw1imjPx+BQeFL LeLcP6ZHQjEodF8/sQ69V+05mIBCuimcO2ifh7FMMSgkr087AM38AHRTDArp uKWRxWDmOXJHRsvd5p/bfxk2NCWggPQYU7SNKxjKnDYm5HIS6liAHNpRTDAs 2M5eje78WY+G3NdaQADIFRBMR0Q+gwnp4mVKZpK/6HEvlfgY6aPdBV7HUAcS XnoBUdzKKJopUQOwNIiQRHALPw0JBz04NPACCb8bdQskLD5CY6KOx2H4+UHC jGR1euYkNc2WNZBQppN+jU6DFfUFU5IqWrT+XlJ+l3pwPlQWUCJjIhlCLfHi 7z5MKM251A0JGJhogmA1oA+DFDPIkPwbBDiAhza6pKeGq3cgpH5ymJS8266F YYkbTLhpsUUJ5P/FgcXPbQRoaqNMtEn4ywbcQEKau8lAgRO4QMcvSh0RVjBN iAcRzILgw6cLhcLA8eUhecL6bxhHPY4QH2bdHyhkRIcMXmNOhK6S+wOFiB0p 54bN5zqM+0AhCQm9nV55DP4xTwwKSdHJQm5fAUID9/2BQopkiytfMLr9Udj9 YeCF7CIfImtpStwAk/c0bX10TYT1xoTgec7+MNBz88TNVzrZrsXkGIPUplj4 4RlJY3Ko1Oh9jBF+miZIc+BCZDpNMRIgEMPP2gQLZpliJ+BOP0X62CXyu6ZY +rnvRQ8qKKT0eMxOI8L7kWDiMOWGGIQyxdI/fF/KpNmF3p+8DQ4cwn7nk9wH XFmbRaCOJw87kQfDVqa4YkJr76Q4xPUZ1BfuQ4SD6Sv6CbjDARZZYj8nsW9u Y7qLJJmXZkTYafWT+9qLQcyTlxkRbvonKY9d8mTfDsWIULaWmYnljncuq7oP ERKWlHPCiCEdgveHCPHDgslcbyArIZRyHyJkEpF0Gon8Ru77GhA2366SfiwG Vyvql6YKKm1cTMP1KzR43R8eZLz5uqAlPEL35P3hwVo0etCKilh/4Y3x4PG9 F7LkjJXfnRXMVywQUNTLcKmMtZpiEyDTU76BCf80oiDGg4sOQAY9i4a1Fvkw HiTZKl1vlCOZNDJhO3fIIOLAOqNzedcJaybj3dh57vYxo40HfdNUOva+fZ5J CR5clMS4+4v7W9wKch8eFMsYecZ5Mf4x/brgQYZtmJ3nZhL0xZQYQZIJigBo PQXNmuL8EABuXF9FRIHVSwginGSnGF5e7hEy24wIwa5MunlmmwZ/U34FI3Ii mwsd0DtTYgroXJ/uhvGkkCk3asVlPszuS95apDqIEJBOpfSiWD3PBBGS1T7N dz1wrYd5EER4GEf9sBHMerdYaRuDQVWR6dJ7Mw91HyLkIiGaobheCRDs/QQR guO5NkLyU8JyJlgRFK3gguA2ECMLcLYcVpP4prIsHQslLFjcKSC9b8yKLMtu AGF3KZamAJz4zdLsEMqwZdANy+UhXkEAoRtdiJewRwpATEl6ROwserwZB6KF 5z5EeNjMYP5FyI8cnynOElwaM6RqOqfmEwgcpEkKFE3xUKKdz9sYcsuXTrnb LguRmYIecKNBp35PyrMeIQWTqUjxMgXJlTrTQmg4mDcUTb/oY5blHMmYySgw dEsjE5RrOEiyawOP6JegNHh/cJB2JjRqMq4lzfOiAweBneX+NS4HiQ8JHJxk nJEqxIcc4X1w0F3493h0gyyZCY6LOlO4yBjRaz1KAAFxMYnIgbMO1wwHAUlc I8A0Qq/IhuGgzMCHqdGPGXe4gQpJk6IDFGDpNfsiNYGD21Ucao22PJYAw0G0 c0Y6Owdr5hgPKri+lPubb1yRDpvyUmQMujc4tDyYfX94kEYwLkLq8E520pQg YsZuDBjoqAkLggfLNvhy7xPDaHmb8SBZRq624Rouxu7uDw7qs2lVoNXe2a1r ONj+9aUjH0PWXDrX/uqBQdorF3fRSUg/yTwEG0Kap7e3IYFWbACB7YNNAftA XFTwQHCl5Fj0ijwl0d+FABi8vuCE8QPJohwmP3f7BCl1jAljcoRMEBIQft0X K3BTUTFvXQ8Ncj+BgvFtmHyOv200WMu3LtF1R2uqCRz99R2CBKttuuLq/X1h InlekmmXfEJ2buWflAh9mdP1NSGmxAcweLq4t2q69d8UlH/4KhNu5iPX9uVl dgHcxMiEjCRGitG8e6NBZmHpBuJeDIHBEUpcAFMfBn64/WVOGg0WeV+GWH2B ITcR1g8PDo9aMnTD+E4WkFho+9ax5lu1uCClfnBwM+RL86hnnqZ3YzjIrNWH 6qFKtOSYYg9Aj/nxbWCDlknzJnDQF2t4up1rD6ePwHCwbKsll4s2mRtCYiE6 U86lfEGXdF7mdjJJnSAD8TWzpSdLSyxEBLcYo5DVYLK0jAYbwkGbn++Lu48D AYMbKOJka5VHuuuBQYVbs3k6ynVTsyZgkBy1rwFlTpNp83pgkHISOQKigevB rfqBwev0ElU8SRTZ6PqBwUtGHUDq++wqKpMcOZ6XHjyGV8VxU8wBGjoWYH1S fqss+jjw6NywSNmDINf7DBqkE1mHQ9aOtoIswGiQTKOgxiD5LCMIwWAQuR+X SiTNdIxd1MOClyl0Oolp/KLdzZTYPwLxRR2Li6q2T81YkLDmMFjL9XKMOZti LIhQcnGGx6GwpmUs2P8lruaiUWZWRg+jjQXplAOKMbs/uCahHha8DpU82/cx 9ZCvpGnADT2bVxFE+TwfFnRPF1VJV+Gj08aCTIHRJ1sM9LiGVz8sSOh3KL6R 4Keppx4WvK7MGE85u22C20fk5Lic9Xqsbkc6AwXJt8jdlifpuEapHhSkFZbu UAs6BUZTbAcmgycDFRlcB5tnHBEs2iZp6zcmzpqNBH2BE5OSInLHgSnGAQCN RpOb9lo9hihIkLtSGUETfKL0YoJ94C5frMYMFrlIvyxAUD5QaE7GnvDrxjsY CC5PBAH3iQvNsv3qhIL7B//ELnPQwYE0UnJx18cAvBTYlKTIXXPagHFqKT60 HTuoRwjGdBLa7fZJBwdy8h0OIARhmWGg4gBhSukmwd1+bigwkOLJZHqbmzdl IExJTOgp6M49gO7ENMUSwEzaIi2xENTtjZ7kBRzuUA8hLZfPOCpuNGvKdjVu aqpwM0CQmWWbIiK9FbcmIIh20Dcvf7BoDl9ZWcokmF8ifVJsYKp6QJAmM67X I3UrCBeCcfCIw6UXmYEzCMaB5Ouhfe8qZC8sOJAWj02MQP2GVGY9GMh1mZNr 8riNilEAUwwDMc90v2LqqTyaYhhIayetJIeMXcU+GQc6LctAtRHP995mKID9 4R5LSnN4P1NQgcNteEXVjy6dAJfgwEnR7TAhdPlStuNgaA1fEUkpl5ZAs6Ai AosmT99/AID00ioxMRlWDzQObmkIxZ6AgMqtoaQfHkwwDiTjR5Fic1Phft7L OND9fvdzi+ygq8MUQ2E5Wm6HZE4dSQ0FFoDEuGNCBwNvg6uCA2s5jzK1qSJe MCXpcSrhLn4DugJ7jAMV9tFCCYaYrmWK3f+8kunmhyBbOr66KdYCqkEYzuO7 N9syBRYUNRPYfGnxar7JMWBwk07PTYrLCVxTQIPlVnUuwZ3MCJUJhoNUL0Ym Owgz8xnHg8O9ZjR00CXt+34fIKT1gQtPjmuJ+b6FAPiKJNFm0/eXfTovSk8Z fcvcEct9ptmnWUBzhdwHNyIy2/9IxoQUNVbusuM2vh2STQE1RsbJuduXOmBI 2ALHvU6dHqfbTEhi4EwvC7fr+ppJsEGOuoGwuV9F4LHeIuIPuH2BZkNuU62w riVDxNgK3V3uXnhnl5IhTkKAQEH570LkHzKkoZF0F1N7pEFyrtEHQ3JGBqYn gEOyQjD1wi1pHznU8b5lcMhFP1oD4wnkA1e+FXRIZwnZKHrke27/NjykRruZ 2VrUjVhIKI6N3FzlbFwF65mUZjKageQXbRbHoyQ4MpIhN09r+n67wjQO7vME tnGDe/kq5wcRJ3Hc5Pg8c/AWYYxINxKQzhdWzS+vC0jEybgnXGESmMYUiwSj GHRWukaa214fShy+BQJ0CUZjJt0kGweZGbrMOi0KvkzKpORKyLx97lqjTT7i Z6BYjh+4jdI1wf6eQiom10v55ncu2WvZr6EiQ0tOAF5fDfTON1hxezxKOs/9 Xt8jBS0C5J1nxBB+71OGi+VrAbj/WSf9PaWaAcyCcINr60lg7pkNGy9uurdo geEOi/VbugEjF5tN30/nizHfKf43YjTFVTQan7kEkmti/v864wXth1lShoRI bYZizEiQV+ym0eT3PZJBI9fruFufWT+FYiatz/q2ue+d3ss9cgfwA420uC26 ern+j7R9SLaWtM7T4EHBhObWkFxNPL7ji2C/ewgqJJsKSR+39lIWPO8634cc aaJgPJv+e66Pi1IFOgLDET9mRNp6sm7sKMxMSX0P3yfxuLRSW5e/4M5cwuuV W8Efety03qRA5RJB1m74iOOZ3Nh3fPF7PbttW7G4hY1sDS1Ov20FQW5afChe 0qNSO2IWCAmgWLRJMi7Z36cMIknHka7inkQS+SElmUDEgcwSmrYvvDCMPNyM 73FRz3GO9ynbzUOrFX99NLXk8IMjybz4dnfq4uP3PnsQQjnGcsWvjBhCOuEF zUXUSlzOyPrOL5+ic2SK1f/vCXmfsCS2rHMJw3CvYnsWxliSW5ycxqZa/J5w RO0MDH34c7hPJCTbTKacKUty9SLZj5D+E0yakhKL8Nd2a8egePOWgM0klyUG MW11nXA0pXy4XPbD/2kCKKS/Ewyi5Nbl6bElau095/4g5cW9M53JFJO+GZpB pS9a595cA5qRjwVVcrdq54aVzlXxM9syrFyez8GxXHoMKvsKrry+RuRjxmAw XRVSMIVwe3MvAN1xT5SMLH2PMLP7CvFouA/FqIIcIjiNIsD6Ht4xtiTvzjVC jeZiRl9NqiArgt7hwOMAzkOygjCJqAMklQACfTAlsOJz4rp3J7p/T71Mm8W9 dd+B+nBKACZovVzZoa3qabcRJviJRtLOvAe3R4ZkiLmGHSwX4H/1Q4XGmIPI xNdKc2PM91xZQCYatZMG8DRTSKBMMqSMoHEtF/S//wFQSwMEFAAAAAgASrE7 LpRklO9yBwAAQB8AAAsAAABsZWFjaC5hbGl2ZT3Zwa0DOQ5AwftGMSG4SZES 809sdqDSv5gnP7RbKsAAv98/v3++/33//7gj7sg71h11R9+x7zh3jK+/jM4n 9Cl9Up/WJ/apfXKfXujFey690Au90Au90Au90Eu91Mv3Q/VSL/VSL/VSL/WW 3tJbeuu9Ob2lt/SW3tJbeqVXeqVXevWOQq/0Sq/0Sq/1Wq/1Wq/1+p2tXuu1 Xuttva239bbe1tt6+10Wva239Y7e0Tt6R+/oHb2jd97t0zt6ozd6ozd6ozd6 ozd6867zf724KuKqiKsiroq4KuKqiKsiroq4KuKqCCqCiqAiqAgqgoqgIqgI KoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKK oCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKo CCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqC iqAiqAgqgoq8KvKqyKsir4q8KvKqyKsir4q8KvKqSCqSiqQiqUgqkoqkIqlI KpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKK pCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKp SCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqS iqQiqUgqkop1VayrYl0V66pYV8W6KtZVsa6KdVWsq2JRsahYVCwqFhWLikXF omJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXF omJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXF omJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXFomJRsahYVCwqFhWLikXF omJRsahYVCwqFhWLikXFomJRsaioq6Kuiroq6qqoq6Kuiroq6qqoq6KuiqKi qCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgq ioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqi oqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgo KoqKoqKoKCqKiqKiqCgqioqioqjoq6Kvir4q+qroq6Kvir4q+qroq6Kviqai qWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgq moqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqm oqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqlo KpqKpqKpaCqaiqaiqWgqmoqmoqnYV8W+KvZVsa+KfVXsq2JfFfuq2FfFvio2 FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2 FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2 FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2 FZuKTcWmYlOxqdhUbCo2FZuKTcWmYlOxqdhUbCo2FZuKc1Wcq+JcFeeqOFfF uSrOVXGuinNVnKviUHGoOFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGo OFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGo OFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGo OFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGoOFQcKg4Vh4pDxaHiUHGo mKtiroq5KuaqmKtiroq5KuaqmKtiroqhYqgYKoaKoWKoGCqGiqFiqBgqhoqh YqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgY KoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaK oWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKo +H5vjfezx/tZ5P1s8n5WeT+7vJ9l3s8272ed9/vn9b6/4Ct+L/m95vei36t+ L/u97vfC3yvHK8ffs75yvHK8crxyvHK8crxyvHK+cr5y/r2GV85XzlfOV85X zlfOV16vvF55vfL6e8OvvF55vfJ65fXK65XrleuV65Xrlevv8F65XrleuV65 XrlfuV+5X7lfuV+5/+7FK/cr9yv3K+9X3q+8X3m/8n7l/cr778q98n7l/crn lc8rn1c+r3xe+bzyeeXzd5tf+bzyvPK88rzyvPK88rzyvPK88vxB+e9f379Q SwMEFAAAAAgASrE7LpXe510OCwAA7iMAAAoAAABsZWFjaC5kYXRhRZpZciQx CET/5xQ+QmkBiftfbBLIVEc4QlhLghBPru7y+P6+v/g3vr/xN26282+MbFd3 77+xsjUOe3efbm43wTX508agqNTGos7YHDF1UHEcdVB0RLeTAU5qzsmWEc5N H9PY4VSaR3u6sMug5vo4ZVF0UXRRdDHMRc3lSsuh1GKYK+hkfzIGxbd2v5VM ZXNr91ux7qO5VwZjNSXVGKtJ1ihrm57NNOLqUbjGcI2qzqz64BJnBpyiLlF/ R68cuI7KKeoqgEPVw1DP5MyzGMfRaR1m9igDhzV1rjqCay5VL1UvQ70M9W5N pOZlTV0FehnoVaBBydD2g5qxuNtgBQQ1Q7sPVVXopCLSzUyURmQ7UCbZThRp tov9FedMmHrc2Y9D+rK9bIPrxidjSFmSY1ELQHHI1CPZcdRz1RM0pkIFVe0T WLFnqWfTF8DikFMQZHGHF0VXRnDV+jhnSRls0ZAy6KIhZfDFVB0KLiUDgLWv /ckYdLGVjf0yrBRvZWMrZhDGyVeGYjbl2RSzSdkUMyBr74CMQ64exWzKsynP rjyDs17lyrNL2aXsry6UDdcJupRdtXE+Lj+qDcDWkwFbx3N0gkd5PsrGUc2d q57gqivlq2xcxXyVZyDHyaY5qrqrmK9ivoo5pBzKRqg2wF3vPVQbIeVQNkJV FzrBqCtiJXlrZDtwzNlOFEC2yLFnixTfbI3jzv7D9Zctam2XTlZrGUPKkgR5 rQXyOGRa5eo5mnPpCOT10FSoc9AnyGPPUs+mL5DXy0FeuwB53OFFmZShHORP OV1SXlOGlNeWYXQK8piqQ8GlZIC89rU/GchvlDGZH5DXOlspBnk0XMbR5Etf WzGb8myK2aRsihnktXeQxyFXj2I25RnkzYrQlWeQ16tceXYpu5RBXu8L5HGy ThDkcZVq43xcflQbII9Di/GAPPboBI+ycVRzII89wVVXylfZAHm9/CrPII+T TXNUdVcxX8UM8no7IWWQ10cQqg2Q10kI1UZIOZSNUNWBPPZEZmwnedDLZx+c QbYTicp2ZQKycHDG2RrHnf2ItdZdttDz0slSKmNIWZIgr7XG1hDObZbh6jma c+kI5PXQVKggr33OqZ6lnk1f07gc5LULkMcdXhxdGcFV66PTJWWQR0PKII+G 0SnIY6oOBZeSAfLa1/5kDBRXGZP5AXmts5VikEfDZRxNvvS1FbMpz6aYTcqm mEFeewd5HHL1KGZTnkHeLqeuPIO8XuXKs0vZpQzyvPYF8jhZJ+hXq1Qb5+Py o9oAeX06IK/jAXmcrBM8ysZRzYE89gRXXSlfZeNOLr/KM8jjZNMcVd1VzFcx g7zeTkgZ5PURhGoD5HUSQrURUg5lI1R1II89kZVgSZ5FttDd2U5sOVuo1vhm v7GF5M0WivX75e+otVk6VcX1cUPKkgR5rQHyOIRa8zKQ3VHG0ZzLAEZVsRV5 vQrktU+Qx56lnk1fIK+Xg7x2MaUM8qInB1fVdVzG4K5AHoekDPI4ZHQK8piq Q8GlZIC89pV118bA8ZYxmR+Q1zpbKd7KMcijcTT50hfI6zBMeTZlw6Rsitne 4ZmGpGyKGeTtHio+rMjrwEBer3Ll2aXsUk7yesg1WXkGeVxVf5msyGPxqDZA Xp8OyOt4QF4XEsjrwI5iBnlcfnleIK9X3cxMGTpBkNcFcJVnkMfJRh2QxyHF DPK6DkFebyc+CoK8PoJQbYTqGeSxR8qhbISU46onshI8yTs7W+jObCdCzXYl mXn9YXvZGsc97zhP8nodLuPqR3a/0qlb3os8KksS5LUWyOMQVEcZlQMv8jjn MoARNKZCBXntE+SxZ6ln0xfI4yqnC5DHHeJZflasQK+X1TNEGQoa6HFI0ktB Az0arlwdKS6lA+y1t7rYy8Bnm6+tyRQBvlbayjLgo+EyjiZfegN8vcqUalNC TMqmqAFfuzfTkKvnRW11Y3jRZyXtyrUPLnPl2iXtkgZ9p2rJXZN1iqCPq1Bv NXQ+Lj9KNejrEwJ9DAj4dTUdY2RH+QB+XH95ZsCPy27dc178sTony+Aq1eBP s41KAJBjCvteluMN7iiUEADYxxCqEADYeQCA7JFyKCGh4ksAuyeqHE59aVnt gEC2E2PZLmwj281x43gV9EkCkdGTBB7PNtjW909lINRWliQIpC+JgsBrZTjd gUAOXfUEjfr4XMbIq+8UgexZ9A4C2xcI5Coo98aOdphfi/UkBb0y7gpkKWog yDFpA0EOmQxXso4kl/IBBNtdPZWUkd+QlZNd1XwKwVbayggQpOEyjiaj5PpI gqvqT0UZg15NykCwcwQEe5WZhpwB2YsaCFqvr4vjFILtwyWdX2t2j6SBYLRh zAMQ5GQdIxCkTlZcFUb+1KSjXIPBPqNksCMCg5xUDwS1hpJgkENXp5YQ9rqb 3WUMFehkJVwlOyHEZ69TELYUIOSYAgeEXcdXRRIfFQFhpxQQdiYAYWcCELLH ZDh1ACHnSDkhREHc+rpzjDSyRG4a+c30SaOU80879uppmKYg5BrBKX4rjaqP /Io3z/cWilEaY3BkPNl8jdB6+bUnnUP6K8n84vOryPJlAuddRpKvE8qor5/K GHlz3QKSPUvGlsd8qdDLPJ9B6hP62y1O0lohuDCRHNW1FP2S+pL62jJMhr/E HWkuJSbfMLTD/T0LKZ81bVeB36Ky5++X9HzNQMufdTT/Km9b0dcjUhkK3qRu i8myl3gzjbnCshc92PQ6CpO4K+9gM2oovwptKZd6vnX42kLsswoEeHL+O1VX bpLPWYk7kj+KHXz2iSWfHRX47CI7dRne4pOa+f6h112dYQLaC2/SUsZ4dTtZ GVeJT0J3BXN1sPkmoo0Xe76LaCO4r/ikma8j+kwS0vKcLyQ6I7HVZTKcqOQ7 CU666oqqkChMcW9EYTp3GrNSm59MsdMvjV0nGMVpz/GKJArUOdO4mhwaGh14 FKt5lNGwtnjC2qJjvxCsniSiYcXJRcPKec9Fvqhoa34v6pH3dRSvY5TcfBtI Ytttvq34ep5LOJmlCFycCnQ+Fwntqr6VKWprakPr+Vj7jb40JbnM5ZHyettI dHvefttIdHfFt6tAo9Cls/0OYtuz3jb20YJb1RTFLmOqTyplDLk3OQC9eGIJ 0ltZT3p7zBWZvR2AXhqR5RRFrwoja7QGk98+Vpd+8jvaQvy7LX8L3knn+4w+ Qu8/glEEM+7zKjVfIPaKhLhjyleILE3Lv23RFHPaeSJXp5oY99L7yW1y3LHn y41ekW83OLoL/CiSeTT5goPW20a+4vgajtAm4xMwRXOdEmju/CTNnZ/YKtMw DbpwSp457b6+qLrB1pNoO2WN2mNaeRZfWfk0Msvab9Se5RVdWvCx27pvbT/u lHKfRpmdqzJ/buqVfmsm3wrInmoSbpxwfnPvCy8hp5mUe+vOZrDM9Na6STod J+oyf/tK2Dd7f94SdzyklRm/DGXI3ZvEW8ew5tvm+nlL6DXBXpCJvSac52L9 EpnkM4b9/cxRlVjmrIeVMtdzvH9Htn97q/8SoHl+y5qhMuMFad+bkBcBw7Gf N6vPM2XtwqxM+43/nNlva1ZfepeVNdKdeSlYl2TdCj0hrwVWgz9feTGw7vJm cK7y36rfoeXlwGP338byeuBu8n7gQeQFwWPPG4LR1hXRCvl/Br2x89tY3hLS uq8W8p64ndC8KFYvy5vCe0JeFSzYvCsYY14Wh732TjKvC5m/rdWF0XuvG6P3 nlcGoal/SOhlMZW8vDWYvLw2uN+wN+6P1Ti/qffX2zfgf1BLAwQUAAAACABK sTsuqNmNxZstAABjZgAADAAAAGxlYWNoLmVuZXJneWWdWZItN5JD/98qtIIy zsP+N9Y4ACPzSW3ValNdz4ggnT7AJ1Yt/+g//yt1X/3Txlqj313r/FPLPxVK L7Wus8s++8y514bS/MwZZ64xalmlr7MulG7KOvPsrXedtq/eDWVAaXXOslY9 eusoZZoy852r/6x9jl6354CwRBjj1HvuXZOvndsh7Ky53dXOqbNPfa8eKCeU eVbbs119T5835fplq9yzVyu9Tf2zvM1w4OjdXX+87u2rbn+n1rxunLvEHf1f uTVLqI8HrczeduvjnlJWSGZCG7X2WmY5a7W5ZzXJXKizzdZm7eLeWHrcpJmn xmji3Zi9audZ4MpDs56lN67W7p2PZE60fls/c/cy9M468r6wYpY5ipZf+lz9 5KGbXRU9Ip7Xu8478faEYde75+bw9r49pI8Vpd+lRbPzs72p1t5xzHaWGFhO q6WY6e2ThyX2aldl17JLMymsuE0bkqhomWvMPDTzkE67SiLn6eeOE8EzK1pr p10xVsck7h4LS9sRo74lPz/imrWbFWKsBHLPKWaJFztPPV408brNM9Y9s05/ q8OMof82dHhD+739ZBU9vNDfdrGqa/16tZfeHyu22Tu0O7FymUs9rNg6/L+E 1gfSx5PaLQk7vbdSJGshzUcq46+nsoqIhXRDvJCsnSuGlJDgxdhVB8zipKVn j7zvU5D69yqiumYFOiURr+PqtE4OZJRQJGA62i6VFjWsHWZF0yqk1pJMba6t 4QMe5kUrOndp2l39DlTepE8s2pq/EpinYica5kDLXnpMWwgpGiLOVp3ukpKP 9qRzRC7qlbz8knzCIypSS9u9zzt6F3nmqTBDci4eScpOO5JuU55YDG3mXqyP TiTaM6Mjt7RVfxXfbJ9PR2rVwW5EZ3VZLZPak/ZxJVCyfxM1N+XJRR+7SA1k M07tsRZzPL6fNaSKElvxK3ZuzsfcpVP52ZU3PG02e5FRxtCVWk5pWcSOHkyd 4qj6/2dKxW2z5rMWFWvfZFHKDvvmpyBSKanq5ZEaAVzPWpTR26/ueHkrnJB+ SB7025hTJ5mnnorogPvQW6WSV9Jk0mOFuHd/tceUx4mDjcBNoWDdK1/Pfcyp 3yfqKuEd5t96GjIktL9HFdfyGU696T+Gcz0V6VWv+zGCWUaYIUekE9zn6lsc N6RdvqfK+o9i7c90rt5/t+UT2dERCYSOFpmV893XK9w9hyVzKmO2dBzSkijx jr1A3VFxffEpz461mDIHE7Ft+OEYkv005Eg/Ja7yjePIKpsUd6oDqtKgggWX bchTJ+sT2xDlgcjIcph0s76y5tVbJYBi7jXpfIKhl9U7j15W9HcmPV7Iapff b5nv5wmGpHz/ehhT+ttWm+viQ7q2lhM5ZoW85RZJK5OucKomPTdy1txDzBOC wE+atJ5Qy7T/wJTjczxPMJY0QLgDHzdG0MB5OtK6fMuP884yYjulPX2w/C4j OSLv9zEDPPLrHf3U/bSkFOmJpFAHXKpZeNtbfMG4/MunXnOj194RC87mVnHL JLghxCRuS8A6B3x63vf8SClyqZ+VGebTfVoiTfyvQbthhkyMnlxVqECwKSDn hhmSZZ3Fz9qzivuEZqI/kra5WOif9sCmdFF81+KaEIl4sqCYFUJn0ps9qlAV 7/Yz5oT4Kfc75ZkmUPNOKI8R+q6MsYy0XipZhBKpGADAe4609ExpKhTzQS5O +9y3ySzJLwhAtKDNi6VAO1gGoARCgIVwhSRJggx/5NyhnFB0gDKYMoK1NnlB KLAA6S+yinpGhlgIzPsMC2QR+5TOYHDldfy2oM0u2yzPIk9WV5kcbPvQptDG Eef42hBUkHK0D23K2QhQis3iIAgjT40wCGBf2ayMjxhi0sxTuDy9rS5gsncb tNmbJERmuV9B165DNyn+YyJev2z1IQVtSiiF7ragv8ys7Es+dUOS/bdG1dFk Lczy9uRBIHX6D2TT0N724U089gQL6Ckh6SwjeLODGroU42BhxGqTIhJCUJLn qb3qXEZOJHhTOqNVH1npLSCxZiQsLqSC8HViFUuL42kf4BzC0Fc/VeyMvHNI 5gZaMcuPyNaQzA2hVhkeyYrYvCRXWeF9+9LqJLo6HDmXMMqA8yKzsrK9X2Oq UB4z5EqFsbA6MoPNQhPE2QduUzqvE5Npz0n2x4yFY/wR3LxwPJm+HJYeVvgE smgf4tT56xs/QpO1B3Eiu5IJ+QIZOgCJSTBDNnbgrBTeSGaaj7g/Hbnn/y/C rFi4df0q663TnH4ogFN/3dEOGdVN4BGSWaHXyDn8Cq5VK4ATkD7+OmFTPpMp w/0jgnndsxQXNkkZZPZ1+GZE4OYYMgV/oaWQIhWDtf+S8sJYi2O9+dHvrCKs kDWXsUJuhyKcYiUeTyrkrGXtEVFpwvAL5zMYC3P6qb75Nz+pkOm1Vb8w0JTH CQF1OTa8s6z9e+gJhdCivI7OXvhFZsWkEa4j6H1dmWmZVitI0KY4K0zxuymv 3GhThy6kLB5IWMTK99COEhyDciEtQREx06RnLRQiE8RNQGCLVgVvStKF428t 9unSRkjBmx2PLr8oRW4gc+8qeLPrV4WLMsGyWPIJMeuftZjeLIhFNAtM8KaE qHPqn+6YFwGcUm5Zbh0/4TPez6TnQoTa9CEJDYHSygqfgshp/2Wm88LPdgIA /207Azg7IUr/jxUM4ERkxiR8ErAVp6EEb+oc5Xx+9KqG9ONHpIufLb7ecfCm AsKLAkziQz3vgwze1HFJpCXm+qhQ1nvheKvQKYHBupahEzXpmU79pOhVIacW pODQpKckE6oEM7jYZ7KfSxWfKnZLaF7gMk+dxycpyU/UGNEN4pRmKUwBwcjN 8VVI53FDWFRATnaag4xUB3HKQEqkf74Vo3U+0VDUfYiSsV41pA9bCDT+nokl NJBT4amQqpCl4JvYtMyNQE7tS+tYhBYyyTeLD+TsrOD8gpU89cKyRSZBCEdW VSs1o85TFAGJ9h9jHMipbxOv/1gTb/l+3FBUJo8hyRHDQqnvJB3Ga3HFoK19 gFN7nUQT3zPW1gBOmUdwlzCpXJ024fUZcIqnwrqgx8FpxpndxwpZpfFrZ3xY 92mJtjX/A2YCOFfBL42FPJFPMCWc0BYVr/175QlEZG1nJYa+ZPf0UH9wU4YO NanwFAlsUMyHzZKRagU2mKkNxXyQ7CtSn8BKXqpIsz+4qWBBHl8nrAevhNrP xFi0Lc46ODi1yAxBMRe2FisZkQMkgiIf1B/c7NqLlJusH8DWL4s0HP5UEahc GBkev+yphqJgwL0kGsM+oBhuNmAroUnFne7s87FAW986U+m1IqTutwVuTgm9 tFO4cF0bZJMeExTHXOy2tis84C8FbsoEEN4pxnGYuUJy9CEmDGdeZSgOwXH/ 0KasFCd3ZA2aRFwgoH9wc8ohY4j1O+hLcWn/4KaMMjKiRQOLVx56CT3xVJZ7 cBrS3mmSpUHwZJEs1fcVAAHY+oc2ZRrkTPU1/aM1euUBm5hFY8NNHC7TblLL +w4ZH32+kCos3lV7yFvSL7smK7xJBHqBAZt7o02KO+V8pp7zAgM2B25MolXI 0ZDEMym8kO2d+o7s1DBwNynOtAgNy+LwOjymxdJgU7oqFdQjwiOyHj3bepoh V042TFGagPLxtoI1HYZJVIToSSF5ff3xoiPqTQwil3F9IMGaDnrBPkJYnfSO SY8Xh4UcxX5E8DekF6KLAwUuXEKEnHCw5qTsgFzoQ3NGAgM1N65GKkBCjJjc FCNNaYfkX15PmkMcZ8p5yxMaq9qpxHNIw02K65DXkJeUFTvSFQKy/mFNuWyd hpy5uFTIjphkVkiIZUA60WRla16fseYg567fyGkXrc+E/uT5IrCyz5eUk1ce rImVJ2knjVNsQ5jRP6yp3Wr5ZOwlMQtU1j+sKU2UKZJEyyiWm+MN1JwgYOoc 4qJcyzNIZgUJ5UGORbIirBLOBmqOQ4KSfKJsmB7yfudnLCTu0whBniBHPz8N 0ZFgAC/GPPYqYFMYZJJcF1hqzkuaFKkQz5ezlw1tCNvn0xC9UR5su+7yxDZo c2KugGPSZPKVPsegTZlMPSMIq0fF6HwKZkwcZ9PPZHvFlLwuYqET1FnJxsnG aN95XXhBzKUXVRLAUhavL2BT5yjz2yhXbZCWeRGwKbeiXxQ0iVObAphJn7Ug +pUz1caEir2MgE0d70VstysfsSPrsUKOoUugW8UARQKDNQ+wT5Is4RUe0StN eoZT75diDXSYd5j0DOeVzfoxnCPbOlngtS50hULke7LAWM6D1Wa/OgCFr+ZT wObQ27ZcjphEbDW9jP28iAJ/WeMDZNQfeBkBm/MgRsLdwrtyfnFLBps6Jfn3 jlNcxGw+x2BNSbp0x9GBoKAEwaRnObVZzv2QNGvh035KUkFwaEGZlDFNesB7 L+JsqZXsI9Wz/mFN+CROiK1ySfUEBRhrAoAoO26qkkJZ/lSgplY7xFnhsgqs jKoGamLNmmMQkIC8o0nPdMrO6GwFE8jEvKf6OxIKdcR4imfFNZOG2aSAAWDo BOiM0p2Xv5EtnpR3nG57KCGCIVsq8VNsQ76yBHMEacohKUgDWsjc9BXnHaRJ VcJZfJSEbJZJTzAUjZE/1FHt8xQ8SFPypZPSM4qrtItYO0PNcSVomIS9LVmW wUBNoap9jau1XSJEkxKEAEfkgQuhqDOi/UFNikJks4QurjBJsQgaag5iSLJZ hYBc0ZkpYcVeQPtCjUK2IcIUpCnw1+UjNvhj4wJMOk9uCdQUOBVjreCs+JGB zusPyMmDkv6MhzU3Fl8+8xKOY0ygWCqurf4A4ncsFITm09UhCbsARySIfUOI RGB5ZFeOAqfLF6FYO+SExM5FmkVuUAYDigVCfkXYQK5I4b6wXPMzRpoDTyXe 6COHDDuEB7a12FJcVRMeHd5MOADvBfvlwnRKwjJQjDQHZdmG+TsTGfQuw4Du 1L1EkqSNJGF8QJOq+8AaVhcTqpdWHwsIweXb5OEIpk2JJFDPlY9YfGsSqY6H M2WmpRBAMSqEgkWmBG5XQkQtW7hQhqXmEAIoqA7JuVFX1ClJ9MeHMzFTHXut r1WYYlIYQQGYvAjwgFyLSRaFTVMAniUAYphH7cnCJK12qFcN8hUmxVzSUNGc YT5kMfJUQDeqiXlrIIAW3gZpunBNjwTpq1Ku+dRiIgTEC55GMiZdz0Nxowur TFlWEAoIaFKYQbAuzAqqlvE7ed+OHC1aEUhDi0myqiYZaJLeFUTFLjdclimx EFJnKjSLnJj+zg91A03y0jp4xWig0eOH+mOF/Qx1ca1TkNyk9uSPhOcEPxnk mPRYgehxUIP8UeQ8QFNnex0lE3Rhw0yKYGhTGBaq1S4ymrTMQNwQlW1hx/me 2f/U/8mcNEpphxIsJdHx4cxlFghRV/kpsciMDc4EcAnbSUJlX6qEENIojyS7 u+UbtHayCyZVM1ZAm9WhHZJtM8IwUxq9pNSHuswmDDelR57JFAku6GXEtnko RkIedKUIuBBTU+ZTqkHyTNGPHJ52btJ6JLlCYDBhl2CNSTGV/Q4sh/Y8FFKV PGWRIOKgWC8h2xTZTXnJXcAfhmjiByLN81kKHL94Lj0UsFle4HwyIbvv9VFm lWU06cWkZzmUBrNKAmP6nkzIupG30JcK4NakJGtoLuHYKRBiuU2KTGgBhbWT wDhSb5NsMqXzDUA+WIhgrymJPtiKJHkRM+vwTYmpWJ0kiuSLXoyVow/MlKeQ N+N3SuHUXscHM8FauI2DsVdwYkqspqwEYLERsup1/tR6lkJuqYEopd+ynCE9 VmjBVB0ktgp+o4nrsULmXmQ5tkWWKiRYIeaRLBwOTEC7psRSNAApTUY6Xe3R lGc1D+HDZzVjKNaLPjC/pNYkugqHsqtYTamtQ0/C7bVy9gGZYg9qiz2jEpxv BWQK7xcKXfqaTprGhfGBzE14oxeyWdmtGNSATBlsaXUBA3HYXkVAJuFRdX6B 7qSWY9zPahZaZNjQoeweUlSkHf81oeqiWGlSQjEZQBw14WI7tBGND2TiXbDS CC3Fi2zrZoFkDGV6CgDp2CidVwAhAyVDpjBjufNjfCBTOEMmbJAicALb2zoP cDvNLbNAYPPcxHnmQg+Q7yzEOQqSTLIHoU9EyJ1a5qa3xZTwQs5Svo2TxK4H oQRkOqFGIoDuHQEBs/38uFOhAAUlALL4xfPkYtIOIrYrdC8t3vQ8b0rlq9Hy pUBTIgIpGFMiSU1J3lRgUwcWEry4OqFODCFv4SSqKY8VBPOUSPCXK8giGJMA 6GJwce17ZVfBmI0yD6krCmkjzsAYMzkUbCqO8+bogzE3ERWtaAqLZEiy32BM fZc8vECfIuoS0QzE3IS20ORapJc5qRuhwAYXylJagv7wzwzCFHjqSBflaAmb lH4GYEp6FPuUZrDRFLVCMLoCbQ6ZAyG/QrwI4eX6CYswOdqVrcQMwKTKKaPj jhoa3/wRmwh9pckkUcYQEJGAzwcvN4cNHweps8vv2bw4TKfnonBN1gjK0wj5 BOmtBBlLWrxFo8vpxjXpfqe1ofplQZckPumeIkTR57vfFnipyI5ayPVxkyk3 6TGANOB1JVGBWTfFtkE7lwiAm2QhRpYddDnJASrWpTtsfW8LxJYQNqD9pXol A2ZSTAN+S+aCyESGuWZ521+S6SFBd0EL7S3cfLgUF6kjkYqZlATmA5cAZTJl wwCcPp75YctLU5y7nSqsOz4hY0uslmw0YQ3lO/mS+aClXkeqd7kWSxXFlEiC 1B/4QRfSJaIwyaIwbU4b/VZkR3ziQZaHvxaMWHb9hJHzQ5Z6QMjwYGu0W3HC pB0JwkDqXTp0EhumGEUsqqhUxScIZGW3ibck6Yf8Kkm4QZPRNLAEnjXSdpeG EultZDtsWARBZPcHUbrXHVgJOKBrSxqOj6556PGBIEiCLGzZ3Ig1P1hJJ8G9 HAleXZbBpOlPdXf34AqR9zy0InlCrZteCoKHbjYEVipM018fSs6H7or5wUod jawHOTuArTy0SREH2Z0GOBpBTVBGjILjTb1OcofPNcVWYYihg0YO4rEn+wGV yzk3UhSoS9gdUElyT/rfqCZQ+opdGPnQIjaQIlMx9U7HfJpUFAg7eSVgHcp6 FNkY3MAl550VxEVMdxoJWhjFxDYEUTaOgDh5k3rr2WqwtXzXIZJvDqi91Rnj QCbsuOQEePCJB09KOiVPJLN0fptYcX54kva5jsII3RbygCa92FMCguM7JMef sZlhw8GUy3KTQ9O/mjLf+457nBXQ0spr3gVO0n8KboFRsnqhWBiak2eHtAEN DSYkxlBEfl3VkVOUFFlUgybpBy2kZy9HrEAD0nrGAdOqQ/fGTrQ5cFLS1Wkk loZSFqv+VuDkpXeqgUKGQooSzVxPLSb9kZRkKfyFEyuckIAPCjpaIykYU+Iq HHYQipGc8u8xkkJwQGByF1piXNt6RlJ6dMHQAipnm63BkvLH0kYJPhZN2pSH rBWVmqNj40O1xSzaTyDkyCj9Tbwrdcn5QUntw/n0RnpqP0kOlBRA60mr0Iv4 LF6gJNUI4Ae9Hq299yXYOm7c3jR9dyJDk5LUPw75SCDSTGLe7WjGoetdZ1hw ARHy/cAT0En4bsLEGYU2kJzj9SgRZ8j4Z7s3q7vEbIoxhCif8wmOlO+tbmSn T2DerCE4khwKbXUYDhqIvPDgSKFAUn3yaCVUkx54kmrKFLdLpeVGLoMj6bIc ZD/l6yfZ2fnhSBa1bT83JcCZVaz3PvkxehILyb/i/Z7IxCJFKTQAuiEtOj8c SfSgE7pEbxSv8qk4DJplhkvLjAl4eYGRmI9OWIrnus+nCkbiSipyvoXGpI8R vvscBlmBMmnxI7oIUnkZbDr19dxx/7PXHRAJowmLCimRFoMYEDlto6gp0G3w 3hbVkODD9UZOmpZfk55quDNSKkrUGUQWEGkjRJmzksRkDmF+IJIKOi5aiyAR XP+sByJxmtcp4uVeWgjJQRQFahwDWVdBDgjGDk4hV1cysR/8nugK8aCiSjFp Dn4fZibZanJVnbjg8rutAsgUQZQi0TCwINg6XidGxUods8yev+CdNzAl3Z8d qyX4ugIgK6EgwzL0Rm0OeT38uECPFpw7XLtfH36kMoCPJJLGMpqSjaNRi75L eeQRVgU9dtDNtMx0BZjeStCjfqMllbEXraB7AUGPpK2bu8blCskPr4cehWYR ZmA34HHnmViDwmnR0jSdtzLFHOgelwLfaGV63pS4ScxukaVahFI1lMQPVKaG uwcaSQofZM6+u/EIM0ANymszcoTJMi00odHrVPJMEDR9K+Lnli8mHbMecExG scFtGWbC7mXciAAY3sh9SivmE6RIQK3eySKc07+Ysj7eiLpIPpI8MyUy4Hmp KwRBJjAEM4AoBZ0W0zpFJFMClmZhFOh4hKNXH3UgY9eXB9UgRtEigT1x5JbJ UMxB8YNclilBzp0OKlwNvbAl4v8YwHQFLXs4wLxshGWMtJ1I844GGC4qVOoU ekiiTkIfU1aUjPDOhZmK6JpihLBt1+EZGbA8EiVQ1IsMSEIHfsmUF0G6sdJl CJwqlKDF5pYh5gBkvJ8OBi2SR2c+btKoIXUzpUU26nJ/VxluETMlFoD2rE2j DgX+yHrAIqUpQjhaZOGSKTOaMzznRLPMjXAELNJoQiLJfeojJz1eRlpyhg3e HjS5MTXmgQSZ3Fmn3VqG2ISwgCoss2BYEGEoKPOlYQ2jiQYpo3QvYSaOpjhH PIaPuuF1sCKpWSJGRhqExyKg89MDKRn5AZ1O88EFKVK6q06eNATHkjNfqcbe Q8pe6LCZIdkWgkWb880N++wdBSliN+TpSNVRLzEhXoBlk2gAmpIsNymImdbk Xam/NIYXvNf1bAGdOIwlgAljwdZXrqJHVIaa4jZ5vfWAoh6ilH7RrUne1JSP C2R1MLNMP5nf67EhfQY0bZP7NOUTBWFAWj9IqcRYrxdEXrLvJGB1Qm+3AYq9 YYfoW0YiI9srFtFtlEgwACDCEJyoH2hNuNRJDTvXw4nEgLJrMlWVbujiJex4 BTK5uBGnvLPVnZLVZXYJkLgbGmuKmXA9WwOapmQaKxKQ6BTFIlUv10A/qkkP G5HPQMgr3akRhqBE/VJdLaDpa0UYdjABEgUWFIqg88KUYxOHSOHCdfLagAlm gse33FODY1xewflCSIYF0eBNZtOU5xobDX/8eJgrMeVJQqGVQrJCnnKZCSdG gV9wTw18Ub0040N6Hhj+EXukY2KrKQkhwWuTRozrQS5TEkaTi6FIqoNF/E2J IGAZCwuRYD/DHHR4aZmtdDWxSL3PpCjENuM6pRMKuEEOUQiFYG7OZ+C0x9UG HdKsL/0+uGKBLRPiG8jQeyQMOxdHcx82IqNTAfDSrTxieLCkqtJ7mfSCIcwj 8Q28yZGsm9R9PsGG97VEboYxPHa0PmyoXTJIeYRn9bUw7r6wSc901w48Cpov WRLoXADbX0SI7uD9sOFkchqYp5UMmRsINQTqIeTzcWHbBHNgTZfn9CGdG8WV /cAh+QOhsUY3BE2ZEAwOPAe3XFh23L8fOiS5QITaMXsiQVjmfmHMmjktTPbl d29dKtNx8YqfpG7Xa4odOKi61AXgQHJxP3BIHEi+vJGopA98P3DIvgHSA7tG j5MpSaKIRzSHLWezjz9f39ZHJtPJhWlppnjvNMNLtIB7nbYpU7x53DRgiphV ZtkE757MPJPIRKAST/OxPmDALqRJWMIbDgcbutVI+kcDAU0P+4OGYiFZw8bM G+kUU3zynTnhRfQmm9pMCDIEGDKjSGKueJPBhSBFnQtWc9L6Y8qLCmh90Uto 0qHDaH/AUEC+MYJGgYWsnik5+3kcfcjw03i0P1zYXfg+YP9Jz4EpK3wh+sM0 4amKd29c6NwNWUu6FxRnmMDuKZ4XWkea55xrKK/asim8Mk7ZSMZYWI0LKX1R oBNeIRVpQgJDihHS5kOOv4TQLDHYKsXAxCZkYk3J9tGrAZztOpqwLLiQroVF ORltfewPLqR6xaiTXCdFbctfcKH8CzZRqkwyY0TBwAMV+yIBmIwjapkm5PjJ A3pgl+rWziNJE5ADGB4ELT3bDCx0zCxdBg7RHmSK5Z+RsuOB5cmNBt6nYCGs IcOTIq5W7NMMKnTfMCMhwBwJnClmwMSPFUxORc9DsQQQrYhxTt91eUJTzIDJ eVGuofmBGYL9YCEl7DmYLPBUx7EEBhW6o5QgWrC0PnUOLASgyB4u91wJzUCZ z/wDZhVKkwaIzgYUInh0jDJZgJ0w5RUX1mGmRO5ca44KBBPK1S3A0mIUjXza /kDhRAeZVKgkgbc5bVBI28x17mQyuR1DF0yI6gkx2z4yBGmKMSE9fLRALFr2 Rx6J9RdcKHAaj3J6mDOjBQypC4scVwNyPCtGgKqoTOqlab1FpAwJJ6N2h04R kotM0O8PEcoIunGG4ibtEKbAA8YrmTNtDM/LpoQycjx0Y1x6AMe3nyDC5VkG +jfoQnwreOl0GowbJvgab+wPEE5yNtPxWZUe+eQCCIX0uElCQI3CWbQqgHCT A5WlQXUEx6wiOzwgFDfOJkiZftt+nqC4tLscqVZbjwBCmtBpgKRu9Gy38WCj iEiDK/kvULEpCRG5pII7RyiDlveZQCGJIEHLoWHlxq3spwmXTBPDR9PdmftD g3JPxw2kEilpaXyk0SCNeQsrNZdrdvuhQeBb95TkIakZVQwaJKan/My9CHSy mBIO0HYjdNXITT4lPc8ZwCyDJI91mNLfGVDboTJI34EJBoPEjEJGlUkfyWEe SZZgkTBd6TYq4VrAoKSfy1qocleE15QIAT6Sy0voKH7e6AQNXGdNCwjSOeL9 sGBlVruVZMEk8qYECg7cvSfRSb3FtgUKUk2gqHm5I6P5M4GC1YVrum6Y5s9G AwXpFb5UmySbUqO8LKkisCgZLA/vXbMgWPC6xkmZVYIvJ2vKCwnoiDqNq07E paxgZ9GHiW/KOh07Ysp5Mr0YnIE3nj/fDwnK5JJCqlgwJgvXn/OQINVMnDWj qgRVEOIPGEKgRES4BX47DwnSlOcpkovA6dTOQ4Kyf+KhcSUTuBOC0QD19UYr rTSX4c/zkKAzzLSWUH4mijoPCTbAlj4jNMj4Cb9753SuoM+TyhhpuvOQIOVa oE3FqnE9xQEJ+hhxhR5KJnzw7gwECF249cg13O1NBAeSYKWODj6UyQhD3sbL dvMBdSQJuSneucwp9S86ixXOP4q3zhw1jcqTLp2a78cAbpDDpXgj2+jfV7bI JCJhHxmNbmbVt3k35XosQ2vJM9k9buiQ6SJnsfN5S77UjiiH7vFGbONDTAQw fA8ATUzQQwkS4i6mjfeuTKCY0J7qyU7IWDM9JsEx5eFgJgwFxgSiNn0l5wOC IE22r4MJ94MDBxs/rrH6XhhTAoMAuRRuEG4haFPsAumPZ8gM5rxzCQ4EGQuB rwxIX4tLe9vHYV4PO5CNtKj6+GkMrDMIeUVUgwOpXjpBicmYflc3CqL5niZw UrQ0jp4PBlKRlFAMZp4E7E0IAmjMwJMbJGtWoyjTLKbzw9ceXRyWCd49Hu+6 FCkGK0A1xSCwcy8BMwJkm4dZGRA4deasmkkobTULSx6A6Q0bNlqPavSxRPE8 fHnpQGX9piD9vjKmH//u0ThTWiA9AVqjjEWmxoT+ZIzy3CT/Bq9NMQO2O/wW VX1HCKb4/Dd6Ac48KTOZ8uQfpOMcilh6zbTxWX6G0Qd2gasyTElTASldJqSP b3AKJQIgDSIApCXEtYDzoUBmOuj4FnwiSvaxBQaiTZWsOe3fDKSfDwZyXRdI glDPaY3zwcDePW4upAPuziNmATgOn0DL0+HigGMUaAMEDqRxjYFg/54oGB33 YMPEoZlgCSBBwg1BsgBFYNOEpIcPd+ZspsIoauZd97GMi6gW/frMykEJApTB rOQk6QbnCEyxAgyPIDEvtsvOwgIAD5OP4BJgC81PxwAQI8uVFQxUycyWrCz4 7zDG2RjfKqBh88X4rzGfwG1wVD3gpykBP6QZmD1qlC1jS4L/GIGRlNMyxaij jyz4zxloqdSk9vjMqfGfbLwBA1MjXIUFIfCP/jRkM3YoKhD4RwKOQWGajPic KUkEUAe4NPkN/LW3E/xH8U9B3+ZOilWjhMF/VN/wrwpHnbc+H/wDCdDGvEl3 7MjM/lSA240kNx6wyzMvETAYotsAdGZTTTH8Izab7lgkR5zd3Ley4koI84s1 h3PCgU0h8dC9zASdFxD4t+kiWb5RhLajuNnnAki3UzKWZM3o7XlWgJtxuLKN TNTy4QT/4SolNtcNpAxBng//0SPQcOSulMbYBP9Nz0QyEzDshk2JEDCESU2d K7a+Z2IFPMA5sCmEdqFEDWTSqRZKGegUNCX4D2C63R1PDiXSHvzHBSG+lQDk /B4JAqYXeNFyyBhRWBD8R3rAYxyNmzsihcF/tA3KRtAbTKY98CSeQO+mK5Ci MP3b54N/pOaxzaRSKr0G54N/tApvJinQHWbczgf/CKyT28Ugl3zmOoWA2ZwM KU66iP/coD8KtUI1w+lixu0g2A8UrnNCQJjaFoKA0ExYXIPD8VD6Wn5Vdu+C J3V9bZ0uzPvQ33YdlDEI8m6d320CiEaGjOn2jLjE/D7051SLtIJcJi0+N+iP s3M3Ls2G9GJA8L4PRQBmYq68LT1v96E/IYjqCykql0z496C/5ZsDWC4jENcE i770QcC7cJPVJlYwJRunVf7QmUUU8yjsfBWbV5rOkX1vPOCPqBhcTcpU/Dch 1o/LAZj+plOhvoWtf+J/O/mhyegyRcD7wT8XpqQRTIkx0WVKtr/oGltcaTJJ ANwP/THzPmiuPLjAYYrRn5ioWOFs9zwAK0yJ3Lu1naEkLh3MuQf9MtmBW6Dy QbH3fugPwHSXIxwcmg8y6I/m7oWSL+qAIcycGEiH+0OLo3NTgoAYSW0MmVQP VpjyymKESJUEAXs1wfgP65r7jS7NVeZZ8N9xYpTec+kleeD78J9vWqA8Q8/m jdwH/y2mfX2RE7c3RbyNfw65XhEQcTkBE7J9T08xeQtCeR9JGYT0K12LzpwN 7z8AkH2QMgRLi6cm+PyLR/gnGJDqrLcfAMj7j+/zJJz09gMAGV3l0iKL8n5L jvMD5JIUoGLAJSr3AUBfvOgmQiBTC/8DAB15neMSNH0r98N/AwbiKy8ju95l 8J/boigq+zojfz7wjw5UrgECTQg1xyIk8Ju8azi74CnY+8E/pi02Db6VDUcz Av+4IJJrrA7g4LzvHOsfnWbHDdPD9Zz74B+xvRbGzWqVMZ3YnuRBieybs8dO FpsSCyCzxsyTuylbjMn86gBCF4f5kbOztKA/bKvgJznky12cpoQFg0apjdMW SppZwExg1LhHkBvL5P39e0JfxtYvHhEM7N99/MzpM8NIzlf20oSkPahXD99U cungMCVJYNoaFWHI1gkW8/vK4dPWXSjSNVptvZFgPwmqh76754P9u20fTdz0 IjJMSvhhiqHf8G2/4iYIP3IU6Ed+rPj2Oir9MReBfvrmXAAiErFPxAL96Cjr LmlSI6jeynrGj+b1QVGcW4PynTSHAIqOsXR3+9P9oF9P1D3J8xN83g/6UX7A 3Xs8//grO06PLpbjjvXLBkxpFiQqqoVpZICE5TXA7zBZhAVEbnZkPMBvHV9M x604FDrzsgS/x41Dm2tOzjML+0l/ZR6Vqva4lBnvQ37T1xZTzWJwYT2naOTH MyRxmE6rkbAgP0aaHUkmRW5ZCvK7mAqKvW6oiIgb+XEPCx8olCZavI+B3yLd g7nimgQ6UUyx9wMfDS48GBl7M8XmD1XmbiIuHbmx/sF9pIlp0fNtl0D8++E+ uSRq91z5jNjkM08CMP2d+1sX/RSmWAK2vTusrL5i0ZQoAONPsBjhWbFZNyrg JCHNMRL16pcF9qEy3AnKqPiNx7wv9Tu5PSq3FXPj2P1g3008SsTKvbU+tJvk D+Mn3D7qDp08YuXnNloKpqRlR5BPUB/NFrRiCIUoZoljCOpjyB9rbeT9LEZQ H/2CG2i/iBfjGYL6hjv6wCVU47jR8cE+xsZcTpIr5c4cUxL/M0bFwBMXmC3f kfyAH6loSrncW4CNMqXnGUlEdfJpYGdNGZFNOgQpDovV+YpNAGMIw/d4ks17 K7P5k5xTq2B+dPWSjxj8dRsmHArXw/qSzKA/LhGjTYT8qnGuKTf8B9seao77 5F2Bf77Jkgp8itGhfArAECj3sw38ZkiPAVxy2XGnEpOd71RbQS7/JsBbFO76 ex8cqG56d1WJivoKxTzgXoHLld2+/si3KX8gEM9IYqx7WNwXnT4UKHtFvZ/4 CCz41pBqaOGSHIax6NV8p2Ac2Fpas/Br0MO7ZhzE7DV5btqjc5fpBwQ3V9tR BmkemTchzuCQ6Ci+IInJppAiCZNOC8a4O6FVGBEoyOwWpV2GwtbNblviAC5l InVNZFvaI5kRXK5B/zjzyeUJUMAg/ZVMzQvcc11AKPCBsVfUkMANDr3X3Scp QMLC1NM5T7qCB2liIUnkvOfI+wwIay5wYUSPi6fzOiNCLlF21VTKwjVDoYQP 9P8LYDHaTfInJBtFHU3xpUqNWzxPuGdQWH29H42ZbRNjhPKiAirdXFBO+P2R jAsOpheUq/3UJ3o9esEMG1cBXLq1vkVEIDxaRlfhod0n2w0y9EXOxRlwrFA+ FWh4uBeWkWrua8M7mNQCHBiAW/TnM0oeSipjja7Vi8/jav9HGs9uEMtRS/FQ WUiRCS47ru5aoysglLCC5AeQjYsy+g3/ghAZ8Fru4tW/UKg2KdUxbmL1/ZPU CUK4T3OFOLgqw3flmDJfagBI2ZldWS4tm1SfKaRNu27f4lKzvGBEqh/cEco4 ED4rpGRIJOUkTTLt3B8pgQKlLOp6Ati0JodkV4Hx5spKBmzKfAu0qewwb3oi nMvCQkmowGgYkSy3OT9LMF+BiD4VrlNgtObZsKDFnQJyYxilzJXTDWBcTqBz 2SFNFTUvDGJcpDzlkS5GYYVJwYzLbV6SFMU+3OYYUkCj7B5X4PnOtPG+FEb4 Zk5aPXxXS7Yb2Jj7aAgOqTE+mQ1uRCbdrMjFdW2Fs+vZS99a6XYXmgJDisE0 YKjcIsNswXvK+jHd+UftpFJVDZsMHumpTSaUPvL5RDPwkdTESYNj8f0MJlk/ djVMliJShs75GkB2X9JEnDGZIXgSuL/0eeOWbzGLMnAoSZwdR/vMM3qAPqSn H7RuynkIKFAFDCkBNDf7+2o96sjvS8eWZ3ORAsO4Y37qZhAJhqauuUkintyD /VAkzUqHbPShg/Y8oQ2M5D7MWf0/t6DYY+eFx5wguUyjQAfMfZTuRRxuInUr ++3P0AZInsx0Hl8Ith4nzkMS3GlHbKodzJ3tGktCIoxCh+nMeE/tx6RC8tnC Xp/bC5p0mdANqZuuireMZBMKB8zY2fJgq0nBk5SqmLXiOm7ukggpGuJmhY7f 4baeUF45oRsccRknXWIh9ejB8d1X9GKSXQ8pmIoRsjvJDu/9ZD2okiTMoreD y2TefgMrj5sC6BJa7pQPKUk1sQlIcWkTmQ8b3JdXcjcrvPD1+iEZWRKHyij0 RFLjz/8BUEsDBBQAAAAIAEqxOy6xXdj6bQcAAEAfAAAJAAAAbXRlLmFsaXZl Pdm7lSQpEEBRfa0YE6ogfvjv2M40l1aKVOodMuFK8f38+fz5/vf9+3OXdZd9 l7hL3qXu0neZuxx/fxmdr9BX6Sv11fqKfdW+cl+9pbfevvSW3tJbektv6S29 pbf1tt5+L6q39bbe1tt6W2/rhV7ohV68L6cXeqEXeqEXeqmXeqmXevmOQi/1 Ui/1Uq/0Sq/0Sq/06p2tXumVXum1Xuu1Xuu1Xuv1uyx6rdd6ozd6ozd6ozd6 ozfv9umN3tE7ekfv6B29o3f0jt551/lfb10V66pYV8W6KtZVsa6KdVWsq2Jd FeuqWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJi UbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJi UbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJi UbGoWFQsKhYVi4pFxaJiUbGoWFQsKhYVi4pFxaJiUbGoWFQsKvZVsa+KfVXs q2JfFfuq2FfFvir2VbGvik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWb ik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWb ik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWb ik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWbik3FpmJTsanYVGwqNhWb ik3FpiKuirgq4qqIqyKuirgq4qqIqyKuirgqgoqgIqgIKoKKoCKoCCqCiqAi qAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgq goqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqg IqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgIKoKKoCKoCCqCiqAiqAgqgoqgIqgI KoKKoCKvirwq8qrIqyKvirwq8qrIqyKvirwqkoqkIqlIKpKKpCKpSCqSiqQi qUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgq koqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqk IqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlIKpKKpCKpSCqSiqQiqUgqkoqkIqlI KpKKpKKuiroq6qqoq6Kuiroq6qqoq6KuiroqioqioqgoKoqKoqKoKCqKiqKi qCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgq ioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqi oqgoKoqKoqKoKCqKiqKiqCgqioqioqgoKoqKoqKoKCqKiqKiqCgqioqioqgo KoqKoqKvir4q+qroq6Kvir4q+qroq6Kvir4qmoqmoqloKpqKpqKpaCqaiqai qWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgq moqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqm oqloKpqKpqKpaCqaiqaiqWgqmoqmoqloKpqKpqKpaCqaiqaiqWgqmoqmoqlo KpqKpmKuirkq5qqYq2Kuirkq5qqYq2KuirkqhoqhYqgYKoaKoWKoGCqGiqFi qBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgq hoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqh YqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgYKoaKoWKoGCqGiqFiqBgqhoqhYqgY KoaKoeJcFeeqOFfFuSrOVXGuinNVnKviXBXnqjhUHCoOFYeKQ8Wh4lBxqDhU HCoOFYeKQ8Wh4lBxqDhUHCoOFYeKQ8Wh4lBxqDhUHCoOFYeKQ8Wh4lBxqDhU HCoOFedHxedn1Qu90Au91Eu91Eu9fEdhf6mXeqmXeqVXeqVXeqVX72z1Sq/0 Sq/1Wq/1Wq/1Wu+vip/3br3Wa73RG73RG73RG72xv3m3T2/0jt7RO3pH7+gd vaN39M67zv96388b433M8T4GeR+TvI9R3scs72OY9zHN+xjnff683vc3+Irf l/y+5vdFv6/6fdnv635f+PvK65XX715feb3yeuX1yuuV1yuvV16vvF95v/L+ /QyvvF95v/J+5f3K+5X3K8crxyvHK8fvF37lH0M/D68crxyvHK+cr5yvnK+c r5y/h/f2nK+cr5yvnK9cr1yvXK9cr1yvXL/34pXrleuV65X7lfuV+5X7lfuV +5V/iP08vHK/cr/yvPK88rzyvPK88rzyvD3P721+5Xnl88rnlc8rn1c+r3xe +bzyeeXzC+Vf+X9QSwMEFAAAAAgASrE7LnEorC4OCQAA8x8AAAgAAABtdGUu ZGF0YT2YW5IdOQhE/72KXsKtEiDY/8YskYeKcQR6VSoBnbann9/f+e/f8/t7 /p4bXoWlYH/vDa5ZKGyFVCiF+6fjgxxCz5LEY8zReoJzm33kHvRebL3jC70X Zy96L3ov5l7cvSndF73103yhtyZR9BZ6y3XvQm/hb+FvoWfka4/2DT2bytnf 6ujsBxF/hp6h5+g5/hw9R8/x5+Tr+HP8OXqOXlC/QC9e5ugFekG+gV6gF+hF ab7xt9Hb+Nv0d/NUNv42+W7y3fRjo5foJXqJXuIvqV+il/hL/CX+knwLvUKv 0Cv0inwLvUKv8FfznK+/+/jO9L1U9Ow9Zt5LRQf7sxtce6GTW7NUKB05gv3F 8yCH0KFC+8a6sx76/FChfeSairepkJ9H55uKt6nQ3IjoHSoUcXeoaN1DhRL6 ab7Ic02i6C30Frku9Bb+DhWaUzXDn+HP0LOpnP15R9f3hwrFzT56hp5TP0fP 0XP0HH9Ovk79HH+OnqMXtDXQC+oX6IVxbnpLvoG/oB9Bfzf+Nv3d+Nv0d/NU Nv42+W70Nv3Y6CV6ib/EXy5eF/VL9JJ8k3wTf0l/C71Cr/BX6BX1K/SKfIv3 Uvirq7cuFR0ehfeYWZcKu8E0c+2FwtZeKpSOHCoU0TlU9PahIjoa6845xA4V 2kfuwdWLrUNFn39f5jh7jejE4NzmXDIv7V/7HR/mkyh6C71FriuY42/hb+HP flQIf0a+NpUzfXeoUMSfUT1Dz/Dn6Dl6jt6hQnP8Ofk69TtUaJ98Hb2gfkG+ Qf0CvUAvprfkG+gF/oL+bvzt+1NlNRVaR2/zVDb9PVR03pt8DxWao5e8l8Rf 4i8Xkfolekm+ST8Sf0m+hb9Cr/BX9KPIt9Ar+lH4K+pX15+JChMVJipMVJio MFFhosJEhYkKExUGFQYV1lRovv52R2PdWUfsUFEdkWsqDCoMKgwqDCqsqdC6 Mw/mm3O3CwYVBhUGFQYVBhUGFQYV1lRof/Md/hb+7p+O+GsqDCqsqei8mgpr KrIj1bPkO/w59XP0HL2mwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCmor2 GeQb9HeTb1NhUGFNRee36cemv02FQYVBhUGFQYVBhUGFQYU1FV2/RC/JN+lH 4i/Jt/BX1K/wV/SjyLfQK/pb+Cvq11S4qLj/qj27Liru3+YKF1gXFX6p6CNb IXUElabCocKhwqHCocKbipZsKrypeJ4eoNdYeGMhQ4/WGwtvLDQ3ohNDwi/2 GgtvLJTRT/NFomsyRa+x8MZCMVjffIe/hT/D38Gi9w09m9IZiRkZHy6eXw82 J1BsMBwwHDAcMLzBUBdw6GTslNBx6Og5ekFng4yDCgYOA72Y9tLfA4aMNhkO Gd5kKNLjQ0ZfvDG4acnG4KYlm4Q3LTlkdExakhhMEs5FnBImgonDg0Y/qsRg knHRk6KChcFCsMi40Ct6XLyZwmBdgyE0QmiE0Lg1PXfHRaOD60hob+u71B4q 9/9WOj7IIXTQeLRgbLi+azZCbGiQfFE4+REfffC+zPHWbESzofn9kRywEc2G 5qW4rskePOT46sOF4EJwOZF811Zqi4wbjgCOaDj6AiNlWyrJhUMHXQIXjrcH m5OkbBTRf5o7KTspOw4bjgCOAI5oOJSaY9GpYdDcoLtNRzQdfWEgGNPhYL5x GslBHO4fkTZvarhxuI19mrJpyubRHDq6FJumHDoUyTjJOJcyzKlhOq8uODgp Nx4BHtF46F3S5cJh4xGNRwsVghVEnk3h8OCx/+2Lh91w1fbFoxfXcX3/Cj1H 788LHblC++LRR1JHSuG5ZPTgQQ+ly0crP8aGS/QJ5nsOpPSfwsqP+OiK92WO udd0w+FD8/7RvBsQHcxZKF15CXl78OiqQ4g2kFzGuhODcmyyW2S9Subtp4MH EV1lpG2LaGR3GJHEhUTfUkhLIg25P1s7kre/uuNAom5g0p1zoXR9k50nBylk 0OIg63iZk3UY56bPNPpCogUcBs3eONz0elPGjcMDic7RmQOJ1sn4QKJabBqT P8qX5Jz0Opes5JQxkUwkc5LO5IvSF/XjfT66s/BYKBavpxCsIG72x2Ndj3k5 8RtuDfNy0otLof+Ku/9E1JkrlReU3uxXmJcUxYvK6gFaD2IXld2Di0o2KtJ9 gsv3nEhd8dw3k82K4sMl78vCmgXTF/dXuFroH9bZuCil5Lb7W9werHG6Hn18 f4+rnTUDZJcTg8Js1Nekv0o5NDIpZPqEYdWWJC4yWnCuv8jom81R0jd6c//1 0HHSb2aymaEzxoJLwamob+7wyd5LJwOfQZeammxq+s5AMabpwbx/nmVTo4OY vG+pI4J7irnH5OFG9vc06ZDDFo/potNV2/Oc8sdKTvJJQZOC5hQ0RzZjBo14 Nj5tKnlQ9ZtX++jiGrcNUDZA2hjRGtHiQV2EurbVD6rEUImhEkP3d2b3s2qI 3htdhy5EJYgKiAqIaiAqICogqoGogKgGogKiEkQ6mrqiISogqoGogKgGogKi GohqICogqoGoBqISRG2kIaqBqAaiAqICogKiEkSd5Jr0G6ICohqICogKiEoQ tYYgKkGkrc1R0m+ICohqICogqoGogKiAqICoBqIaiAqICogKiAqIqiHSHYFk TNeD+cZtU1RQVE2RvtxI7innxahrIYxKGGlr2rR5TjtxvOdBCaMajAqMCoxK GOktTveFUQ1GBUYFRjUYFRjVYFRgVGBUg1ENRgVGNRjVYPT8xNGNtwQ33rd/ Y1f1DpqlO3BOXppu3HMiR6tmRUj1aHSfERZVPbpY9cBHocHqwT7saJTc12y1 xd8Mnvmu8erB+paM795PXYj1aE+6n/lLmTaFWY8eNARaj74L1lzQrPUgpnh7 8l+ffvN2Bw1cD545ZWO/meuBTf6irkdxUtdoz/nkxibvDhq9HnzFafh68Hlv /HrgKPlU3j/v/nlvBu8gxntMXxvDHnwvJkY8vicTs7InhRjnMc6FY49GfH9l F5E9su/Y19j9NXZ/r1Jc9uh7lyKzR8+3NrXPqX1+tReePYpvtOd1NKE9mJd5 GQWFh6zqS6Ex7cGXQX369enXPM36Eqh+mv8BUEsDBBQAAAAIAEqxOy4QuM6r BQEAAIABAAAOAAAAY29uZGl0aW9ucy50eHRVkF9PgzAUxZ/XT3EfNXGkZQPE xBeVGE2mBlji23IHF2jSUdJ2zn17Cxj/NH0459xfTm7LtsXTyyNsygzy123p NWOFPBwVOql7OEmlwDo9ADaODAjOwVKl+9oG7A4t+eFMooMLfgX8kmVYddDr epoZJ/vW17gOQnjWR0UWdAPUk2nPAWPZJGDjcXXDFov8vewM2Q5uIaZl6pP7 4icRc5LvJx17mX1WH8a7iM+jrDHS2h0eBh+mQZysRRylXEQ8jBIe0lKEI+VO emfw/M2JYMVXyd/ruWjk9s3YPVe/yVqRt3zUVhENk2HFYAjr8ZUNVk6P2wj2 gA5BYQvSwjpI0n/n+vcL2RdQSwECFAAUAAAACABKsTsuTILBkOcuAADfZQAA CgAAAAAAAAABACAAtoEAAAAAbXRlLmVuZXJneVBLAQIUABQAAAAIAEqxOy6U ZJTvcgcAAEAfAAALAAAAAAAAAAEAIAC2gQ8vAABsZWFjaC5hbGl2ZVBLAQIU ABQAAAAIAEqxOy6V3uddDgsAAO4jAAAKAAAAAAAAAAEAIAC2gao2AABsZWFj aC5kYXRhUEsBAhQAFAAAAAgASrE7LqjZjcWbLQAAY2YAAAwAAAAAAAAAAQAg ALaB4EEAAGxlYWNoLmVuZXJneVBLAQIUABQAAAAIAEqxOy6xXdj6bQcAAEAf AAAJAAAAAAAAAAEAIAC2gaVvAABtdGUuYWxpdmVQSwECFAAUAAAACABKsTsu cSisLg4JAADzHwAACAAAAAAAAAABACAAtoE5dwAAbXRlLmRhdGFQSwECFAAU AAAACABKsTsuELjOqwUBAACAAQAADgAAAAAAAAABACAAtoFtgAAAY29uZGl0 aW9ucy50eHRQSwUGAAAAAAcABwCMAQAAnoEAAAAA --0-1112398238-1044109163=:69821-- From mistry55@hotmail.com Sat Feb 1 07:30:02 2003 From: mistry55@hotmail.com (Manesh Mistry) Date: Sat Feb 1 07:30:02 2003 Subject: [ns] tcp over a wireless network Message-ID:

Thanks for the tip....

Ive finally started to get my head round the basic concepts of running tcl scripts in ns to simulate basic wireless scenarios!

I was wondering how would i go about working out the "throughput" and "goodput" for the wireless1.tcl example, and then display them in graphical form!

Any help would be most helpful

Thanks

Manesh

>From: "Alfredo Grieco"
>To: "Manesh Mistry"
>Subject: R: [ns] tcp over a wireless network
>Date: Sun, 26 Jan 2003 13:21:16 +0100
>
>look at wireless1.tcl (it is a script used in the ns tutorials)
> -----Messaggio Originale-----
> Da: Manesh Mistry
> A: ns-users@ISI.EDU
> Data invio: Saturday, January 25, 2003 3:28 PM
> Oggetto: [ns] tcp over a wireless network
>
>
> Hi all........
>
> I wanted to simulate TCP over a basic wirless network? Does anyone have any scripts that i could try out??
>
> Thanx
> Manesh
>
>
>
>
>------------------------------------------------------------------------------
> Protect your PC from e-mail viruses. Get MSN 8 today.


The new MSN 8 is here: Try it free* for 2 months From gagutierrez@ISA.com.co Sat Feb 1 11:05:07 2003 From: gagutierrez@ISA.com.co (gagutierrez@ISA.com.co) Date: Sat Feb 1 11:05:07 2003 Subject: [ns] WRED Implementation Message-ID: Hi, all Do you know if exisist some WRED-Diffserv implementation in ns? Thanks German From yasser.lotfy@lycos.com Sat Feb 1 11:55:03 2003 From: yasser.lotfy@lycos.com (Yasser A. Lotfy) Date: Sat Feb 1 11:55:03 2003 Subject: [ns] DiffServ question Message-ID: Good day, I am trying to create policy entry using addPolicyEntry like this: $qEdgeCore($e) addPolicyEntry [$mobileNode($m) id] \ [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 the problem is that the more nodes I ad, the bigger the table gets, then I have to go to ~/ns/diffserv/dsPolicy.h and increase the MAX_POLICY_ENTRY beyond the usual 20 which berings the running speed of ns significantly down. Is there any generic policy entry to a group of nodes or to all nodes like for example: $qEdgeCore($e) addPolicyEntry -1 \ [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 To indicate that $coreNode($c) should acept any traffic (coming from any source) and provide QoS based on the DSCP of the traffic? Also can you direct me to how to mark traffic with correct DSCP at source nodes? Appreciate your help Yasser carleton University _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus From hemant@cs.cmu.edu Sat Feb 1 14:55:07 2003 From: hemant@cs.cmu.edu (hemant) Date: Sat Feb 1 14:55:07 2003 Subject: [ns] need mglinstaller urgently Message-ID: Hi, If anyone can send me the mglinstaller for linux (or for windows), i would be very grateful. Thanks hemant From nsuser2001@yahoo.com Sat Feb 1 16:30:01 2003 From: nsuser2001@yahoo.com (Aniruddha Bharadwaj) Date: Sat Feb 1 16:30:01 2003 Subject: [ns] TTL in UDP and Randon packet size Message-ID: <20030202002519.27802.qmail@web21104.mail.yahoo.com> HI All, I tried to use Network Simulator to implement some algorithms. Would you please help me on the following problems? 1. Cross traffic How to generate random size and random interval cross traffic packets by using TCL and Network Simulator? I used Pareto ON/OFF UDP flows to simulate the cross traffic. But it doesn't work and I don't know how to setup the random size. 2. How to setup TTL for UDP packet? I tried to setup the TTL (time to live) value of UDP packet: set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 1000 $cbr0 set interval_ 1 $cbr0 set ttl_ 1 But, it doesn’t work. This UDP packet still goes to the node 2 and node 3 instead of stopping at node 1 and sending ICMP packet back. Thanks for your help in advance. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From rameshr657@yahoo.co.in Sat Feb 1 18:20:02 2003 From: rameshr657@yahoo.co.in (=?iso-8859-1?q?Ramesh=20Rajagopalan?=) Date: Sat Feb 1 18:20:02 2003 Subject: [ns] Problem when running TORA?? Message-ID: <20030202021501.59253.qmail@web8205.mail.in.yahoo.com> --0-1782661018-1044152101=:58158 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi ! When i try to simulate a wireless network with TORA as routing protocol, the simulation stops in between giving the following message : bus error . Does any one have any idea what this means? In my trace file the simulation has stopped at 7.25 seconds. Can any one please help me on this? Ramesh Ramesh Rajagopalan Graduate Student Department of Electrical Engineering Syracuse University New York Catch all the cricket action. Download Yahoo! Score tracker --0-1782661018-1044152101=:58158 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi !

When i try to simulate a wireless network  with TORA as routing protocol, the simulation stops in between giving the following message : bus error . Does any one have any idea what this means? In my trace file the simulation has stopped at 7.25 seconds. Can any one please help me on this?

Ramesh



Ramesh Rajagopalan
Graduate Student
Department of Electrical Engineering
Syracuse University
New York

Catch all the cricket action. Download Yahoo! Score tracker --0-1782661018-1044152101=:58158-- From chnam1@ie.cuhk.edu.hk Sun Feb 2 05:15:18 2003 From: chnam1@ie.cuhk.edu.hk (Nam Chung Ho) Date: Sun Feb 2 05:15:18 2003 Subject: [ns] dist0_ of shadowing model Message-ID: I'm doing some simulations on the shadowing model of 802.11. But I have no idea on setting the parameter "dist0_" in NS2. Could anyone tell me the traditional value of dist0_ of 802.11 network?? Thank you very much. Regards, Nam From killa7881@libero.it Sun Feb 2 05:15:36 2003 From: killa7881@libero.it (Emiliano Graziosi) Date: Sun Feb 2 05:15:36 2003 Subject: [ns] Help with NS code Message-ID: <000f01c2caa1$f28011a0$6bd11897@acertravelmate> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2CAAA.544479A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My scenario is: Wired Node | ------------------------ LAN | BS Wireless nodes I estabilish the following connections: 1. FTP source over TCP on the wired node and the sink on the wireless node: that's all ok, I have no problems 2 FTP source over TCP on the wireless node and the sink on the wired node: I get the following warning message (strangely just for the first few packets): warning: Route to base_stn not known: dropping pkt I'm using the dsdv protocol and a hierarchical addressing. I'm looking the "DSDV_Agent::forwardPacket (Packet * p)" function code in dsdv.cc in order to understand what happens. but I find some difficulty, so I ask you for help. 1. In the line: prte = table_->GetEntry (dst); the GetEntry() function is called, it's defined in the RoutingTable class in rtable.h, it gets the entry for an address and uses the bsearch(&ent, rtab, elts, sizeof(rtable_ent)) function. where is it defined?? 2. I can't understand the first part of the statement: if (prte && prte->metric != BIG) what kind of control is if prte??? Prte is a pointer to a class. which field of the class I control by means of the if?? I thank you a lot in advance. if you can help me in any way (also giving me the solution to the problem :-) ) I'll appreciate it! Best Regards Emiliano Graziosi ------=_NextPart_000_0010_01C2CAAA.544479A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= o:p>

My scenario is:

 

        Wired Node

       &nbs= p;         |

       &nbs= p;        ------------------------ LAN

        = ;            =             &= nbsp;  |

        = ;            =            &nbs= p;   BS

        = ;           &nbs= p;     Wireless nodes

 

 

I estabilish the following connections:

1. FTP source over TCP on the wired node and the sink on the wireless node: = that’s all ok, I have no problems

2  FTP source over TCP on the wireless node and the = sink on the wired node: I get the following warning message (strangely just for = the first few packets):

 

warning: Route to base_stn not = known: dropping pkt

 

I= 217;m using the dsdv protocol and a hierarchical addressing. I’m looking = the “DSDV_Agent::forwardPacket (Packet * p)” function code = in  dsdv.cc in order to understand = what happens… but I find some difficulty, so I ask you for = help.

 

1.       In the line: = prte =3D = table_->GetEntry (dst); the GetEntry() function is called, it’s defined in the RoutingTable class in rtable.h, it = gets the entry for an address and uses the bsearch(&ent, rtab, elts, sizeof(rtable_ent)) function… where is it = defined??

2.       I can’t = understand the first part = of the statement: if (prte && prte->metric !=3D BIG) = what kind of control is if prte??? Prte is a pointer to a class… which = field of the class I control by means of the = if??

I thank you a lot in advance… if you can help me in any way (also = giving me the solution to the problem J<= /span> ) I’ll appreciate it!

 

Best= Regards

 

Emil= iano Graziosi

------=_NextPart_000_0010_01C2CAAA.544479A0-- From inversiones@ecuadorproducts.com Sun Feb 2 05:15:52 2003 From: inversiones@ecuadorproducts.com (customer service) Date: Sun Feb 2 05:15:52 2003 Subject: [ns] Invierta o venda su propiedad en Ecuador Message-ID: <200302021223.h12CNwD28744@gamma.isi.edu> Page Title

 

Revise esto en 1 minuto, puede ser de su interés:

 

Busca invertir o requiere inversionistas en el Ecuador? ofrecemos más de 100 selectas oportunidades para usted en Bienes Raíces: Haciendas, Fincas, Casas, Terrenos, Departamentos  Locales Comerciales y negocios instalados. Visite nuestro website www.ecuadorproducts.com, para que tenga idea de precios y escríbanos comentando lo que requiere.

 

Utilice nuestros servicios para anunciar al mundo lo que vende, nuestro marketing le da vuelta al mundo. El Ecuador ofrece muchas alternativas y precios competitivos, los extranjeros lo están descubriendo,

 

Vende o requiere un negocio instalado y funcionando? Contáctenos   

 

If you have interest in Real Estate in Ecuador please let us know: info@ecuadorproducts.com

 

100 + propiedades en Ecuador disponibles para usted

 

For Sale \ De venta

 

Beautiful fully-equipped property with 15 level hectares, 4 hectares of greenhouses (metallic structure) with computerized irrigation system, 15 hectáreas listas para floricultura, horticultura u otros proyectos. Price: US $1’800.000 (English description...)

 

For sale in preconstruction 29 beautiful apartments in Quito low prices, encuentre el mejor departamento para sus necesidades al norte de Quito Prices starting at: US $59.687

 

New houses in Cumbayá : #1,  # 2,  # 3,  #4,  #5, ! Look each of our exclusive homes , click the number you want. Revise una a una estas preciosas casas listas para usted y su familia.

 

Country  State - Hacienda: 400 hectare / hectáreas

988.4 Acres. Ideal for: Livestock - Farming -Tourism - Ecology  investments. Apropiada para inversionistas en : Ganadería, Agricultura, Turismo, Proyectos Ecológicos. Price: US $ 700.000

 

Four hectare premium City Land, 4 hectáreas de terreno en Quito,

40.000 mts2 \ 9.88 Acres. Ideal for: Tourism - Ecology - Educational - Religious - Diplomatic investments. Apropiada para inversionistas en : Turismo, Ecología, Educación, Religiosos o proyectos Diplomáticos Price: US $ 1’800.000

 

8311 mts2 \ 2.05 Acres premium land close to the equator line.

 Ideal for: Develop medium or high residential complex, tourism projects or other profitable interest. Cerca a la mitad del mundo, área de Pusuquí. Apropiado para desarrollar Complejos Residenciales de clase media y alta, Turismo u otros. Price: US $400.000

 

9232 mts2 \  2.28 Acres premium land in Quito, close to the most successful Mall in Quito, great investment ! no comments, just look. Gran inversión cerca al más exitoso Centro Comercial del Sur de Quito - El Recreo Price: US $ 1’447.600

 

12.250 mts2. Premium land in front of the Beach (Pacific Ocean): Playas-Ecuador. Excelente inversión frente al mar entre Playas y Posorja. Price: US $ 20.00 p/mt2

 

Short Term Rentals: MIAMI \ negocios o vacaciones?

Business or Vacation in Miami ? We offer furnished apartments for temporary rentals in the best areas: Doral, Brickell, Miramar , Si viene a Miami por negocios , vacaciones o compras mire lo que tenemos para ofrecerle en renta temporal en el Doral, Brickell y Miramar…

 

12000 mts2 \ 29.65 Acres premium land in the -Condado- close to the most exclusive Country Club in Quito, Ideal for residential complex. Localizado en El Condado, uno de los mejores sectores de Quito, excelente inversión. Price: US $ 780.000

 

New Office Building in the Condado Area, finance available. 

Edificio de oficinas, ideal para consultorios y otros servicios profesionales, financiamiento disponible.

Price: US $480.00 e/mt2 (c/mt2)

 

Land for residential projects, finance available -Condado Area-: from 516 mts2 to 1033 m2 /.12 to .25Acres  Price: US 100 e/mt2

 

Valle de Los Chillos Land 1 hectare, Quinta 10.000 Mts 2 Preciosa Quinta Price: US $ 400.000

 

Luxury apartment 5 bedroom 4.1/2  bathroom Quito Tenis, departamento de venta: 5 dormitorios 4 y 1/2 baños, lujoso , revise detalle completo... Price: US $195.000

 

Lovable and beautiful apartment located at Monteserrin area Quito 2 / 1-1/2, Departamento de 2 dormitorios, sala, comedor, cocina, área de lavandería, 1 ½ baños, 1 garaje, 1 bodega

Price: Just US $ 44.000 !!

 

Three BRAND NEW apartments Monteserrin area Quito, Hermosos y por estrenar, 3 departamentos en una de las mejores áreas al Norte de Quito Price starting at US $69.000

 

Spacious apartment Bosmediano area, Departamento grande y confortable en la zona de la Bosmediano  3 dormitorios amplios, sala, comedor en un solo ambiente, cocina, área de lavandería, área de servicio,  sala de estar, jacuzzy, 2 estacionamientos, 1 bodega Price: US 185.000

 

29 apartments in pre-construction , low prices! close to SEK  Quito, venta en planos, 29 preciosos apartamentos en edifico de 5 pisos.  Price starting  at US $59.687

 

BRAND NEW !Great house in Cumbayá 509 mts, close to many services FINANCING AVAILABLE, hermosa casa con todas las comodidades y cercana a todo tipo de servicios, FINANCIAMIENTO DISPONIBLE. Price: US $314.000

 

NEW house in Miravalle, Valle de Cumbayá, 20  minuts from Quito 3 bedrooms and all services, close to Quito, complex pool  FINANCING AVAILABLE. Hermosa casa, área de construcción:  470 m2 área de terreno: 325 m2 FINANCIAMIENTO! Price: US $286.000

 

NEW house in Miravalle - Cumbayá. Construction area:  437m2 Land 478 m2, 3 bedroom, complex pool. Financing available, conozca nuestras casas en Cumbayá, ésta puede ser la de sus sueños. FINANCIAMIENTO disponible. Price: US $ 270.000

 

You must see this one year old huge house, construction 406 m2 land 706 m2, 3 bedrooms and all services, complex pool FINANCING AVAILABLE! otra gran propiedad para que usted pueda escoger su estilo de vida, FINANCIAMIENTO disponible. Price: US $255.000

 

If you are looking for a house in Cumbayá this is the ONE! ask for details, 3 bedrooms, construction 406 m2, land 460 m2, pool in the complex. Gran inversión, todas nuestras casas son opciones para usted, piscina en el complejo Price: US $235.000

 

Super located offices in Quito from 20 m2 to 63 m2, CUSTOMER PARKING! Financing avail.oficinas en La Gaspar de Villarroel con espacio de parqueo para clientes, Financiamiento disponible Price: US $850 p/mt 2.

  

4 years old house, 5 bedroom, 460mt2 construction located at El Condado, Ubicada dentro de condominio exclusivo y seguro, contáctenos. Price: US $ 260.000

 

Huge house in EL Condado, 5 bedrooms, great investment, para familia grande o que guste de cómodos y acogedores espacios. Price: US $250.000 

 

Apartment in El Condado 4 years old, 275.62 mts, hermoso departamento Price: US $135.000 

 

Apartment in El Condado 4 years old, 322.80 mts, hermoso departamento Price: US $190.000 

 

Apartment in El Condado 4 years old, 140.00 mts, hermoso departamento Price: US $85.000

 

Apartment with a magnificent view to Quito! located al Colinas del Pichincha, muust see.. 209.53mt2, hermoso apartamento de 3 dormitorios y 6 años de construido Price: US $ 145.000      

 

Beautiful 82 mt2 apartment with 70 mt terrace in Monteserrín, 2 bedroom, hermoso departamento localizado estratégicamente en Monteserrín. Price: US $ 48.000

 

Commercial Space with customer parking - 2 locales comerciales en El Condado 110 mts2 and 230 mts2 por estrenar, Price: US $850 p/mt2

 

 

Más propiedades... ! / more properties click here...

 

For rent \ Para arrendar

 

 Beautiful Furnished House for rent, El Bosque 4 Bedroom 3 bathroom, Lista para arrendar  hermosa casa  de 4 dormitorios totalmente amoblada.

Monthly \ Mensual: $1500.00

 

Classifieds \ Clasificados

 

12.250 mts2. Premium land in front of the Beach (Pacific Ocean): Playas-Ecuador. Excelente inversión frente al mar entre Playas y Posorja. Price: US $ 20.00 p/mt2

 

We are looking for \ Tenemos inversionistas listos:

 

-Buscamos en Quito 2.000 mts.2 de oficinas, de preferencia en 2 plantas libres, indispensable acometida para 20 líneas telefónicas y 50 parqueaderos, zona norte, contáctenos: info@ecuadorproducts.com

 

-Buscamos en Quito local comercial, oficina o casa que se pueda acondicionar: de 100 m2 aprox., con facilidad de parqueo y líneas telefónicas, entre Patria y Gaspar de Villaroel y entre Eloy Alfaro y América.  Preferible al exterior.

 -Buscamos terrenos en Cumbayá -Tumbaco (preferible Cumbayá).  Tenemos un pedido de 1000 a 1500 m2.

-
Necesitamos 2 casas dentro de un condominio o una misma propiedad en los valles aledaños a Quito, preferible en estilo rústico, no necesita ser de lujo, escencial que sea en  un lugar totalmente silencioso y seguro, cocina grande, puede tener desniveles.

 

SHORT TERM RENTALS: MIAMI \ negocios o vacaciones?

Business or Vacation in Miami ? We offer furnished apartments for temporary rentals in the best areas: Doral, Brickell, Miramar , Si viene a Miami por negocios , vacaciones o compras mire lo que tenemos para ofrecerle en renta temporal en el Doral, Brickell y Miramar…

 

Tiene propiedades para vender o quiere comprar? Contáctenos

 

www.ecuadorproducts.com

 

Promovemos lo mejor de Bienes Raíces del Ecuador en el mundo

 

E mail: inversiones@ecuadorproducts.com

 

**************************************************************

Si desea que no enviemos más e mails con oportunidades de negocios a su dirección solo conteste ELIMINAR en la línea de referencia.\ Please replay REMOVE to be eliminated from our business list.

From patilabh@msu.edu Sun Feb 2 08:10:01 2003 From: patilabh@msu.edu (Abhishek Patil) Date: Sun Feb 2 08:10:01 2003 Subject: [ns] Wireless Simulation In-Reply-To: <20030201021536.74838.qmail@web40612.mail.yahoo.com> Message-ID: <20030202160930.77214.qmail@web10906.mail.yahoo.com> Hi Bhaskar, Thank for the reply. I am testing out the code that came with the NS (2.1b9a) installation. I have not yet started testing my own code. So, is there something in the sample code that come with NS that has some problem that i need to correct? Regards, Abhishek --- Bhaskar Anepu wrote: > > > One reason for segmentation fault might be that you > are dividing something with zero somewhere in the > simulation. Another reason might be with the memory > locations. That is when your code tries to mess up > with them. Thanks. > > Regards, > Bhaskar > > --- Abhishek Patil wrote: > > > > > > Hi All, > > > > I made the relevent changes to eliminate the > > -channel warning. > > I couldnt understand the reason for doing it. I read > > the note in the file > > 'wireless-mitf.tcl' regarding this. But it doesnt > > explain much. Can > > somebody explain it to me please. > > --------------- > > [root@localhost ex]# ns wireless-shadowing-test.tcl > > num_nodes is set 2 > > warning: Please use -channel as shown in > > tcl/ex/wireless-mitf.tcl > > Starting Simulation... > > NS EXITING... > > -------------- > > > > > > Some of the simulations were giving me a > > segmentation fault. What can be > > the reason?: > > ----------------- > > [root@localhost ex]# ns wireless.tcl > > num_nodes is set 50 > > Loading connection pattern... > > Loading scenario file... > > Load complete... > > Starting Simulation... > > Segmentation fault > > ------------------- > > > > > > Thanks & Regards, > > Abhishek Patil > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up > > now. > > http://mailplus.yahoo.com > > > > > ===== > MobNets, > The Mobile Networking group of > WINLAB, > RUTGERS, the st univ of NJ. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From patilabh@msu.edu Sun Feb 2 08:20:02 2003 From: patilabh@msu.edu (Abhishek Patil) Date: Sun Feb 2 08:20:02 2003 Subject: [ns] cmu-scene-gen using setdest In-Reply-To: <20030202160930.77214.qmail@web10906.mail.yahoo.com> Message-ID: <20030202161710.279.qmail@web10902.mail.yahoo.com> Hi All, I am trying to generate some ad-hoc scenarios using the setdest program in the ~ns/indep-utils/cmu-scen-gen/setdest directory. I followed all the instructions (for installations) given in the READ file in that folder. However, when I run make, it exits abruptly without any error. And when I try to run ./setdest it gives me an error saying no such file or directory. Am I missing something here? I am appending the last few lines of make: ------------- cc -c -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -Wall -Wconversion -Wno-i mplicit-int -fPIC -I/home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/unix/../ generic -I/home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/unix -DHAVE_UNISTD _H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHA VE_STRTOL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PA RAM_H=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM _ZONE=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_ HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_SHLIB_EXT=\".so\" /home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/uni x/../unix/tclAppInit.c cc -rdynamic tclAppInit.o -L/home/abhishek/NS-2/ns-allinone-2.1b9a/ns-2.1b9a /indep-utils/cmu-scen-gen/setdest -ltcl8.3 -ldl -lieee -lm -lc \ -Wl,-rpath,/usr/local/lib -o tclsh [root@localhost setdest]# ./setdest bash: ./setdest: No such file or directory ----------- Please advice. Thanks & Regards, Abhishek __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From nicolas@cs.virginia.edu Sun Feb 2 08:45:02 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Sun Feb 2 08:45:02 2003 Subject: [ns] cmu-scene-gen using setdest In-Reply-To: <20030202161710.279.qmail@web10902.mail.yahoo.com> References: <20030202161710.279.qmail@web10902.mail.yahoo.com> Message-ID: On Sun, 2 Feb 2003, Abhishek Patil wrote: > I am trying to generate some ad-hoc scenarios using the setdest program in > the ~ns/indep-utils/cmu-scen-gen/setdest directory. > > I followed all the instructions (for installations) given in the READ file > in that folder. However, when I run make, it exits abruptly without any > error. And when I try to run ./setdest it gives me an error saying no such > file or directory. Am I missing something here? > > I am appending the last few lines of make: Unfortunately, this does not make much sense to me. Could you please: go to the setdest directory, run make >make.out 2>&1 And post your make.out file (don't snip anything). If it's too long, i.e., more than a dozen lines, send it to me only (leave ns-users@ out), I'll edit it in my reply. Regards, -- Nicolas From xuanc@ISI.EDU Sun Feb 2 08:45:14 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 08:45:14 2003 Subject: [ns] cmu-scene-gen using setdest In-Reply-To: <20030202161710.279.qmail@web10902.mail.yahoo.com> Message-ID: could you please check if the binary setdest is really in that directory? On Sun, 2 Feb 2003, Abhishek Patil wrote: > > > Hi All, > > I am trying to generate some ad-hoc scenarios using the setdest program in > the ~ns/indep-utils/cmu-scen-gen/setdest directory. > > I followed all the instructions (for installations) given in the READ file > in that folder. However, when I run make, it exits abruptly without any > error. And when I try to run ./setdest it gives me an error saying no such > file or directory. Am I missing something here? > > I am appending the last few lines of make: > > ------------- > cc -c -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -Wall -Wconversion > -Wno-i mplicit-int -fPIC > -I/home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/unix/../ > generic > -I/home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/unix -DHAVE_UNISTD > _H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1 > -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHA > VE_STRTOL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 > -DHAVE_SYS_PA RAM_H=1 > -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM > _ZONE=1 -DHAVE_TM_GMTOFF=1 > -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_ > HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 > -DHAVE_SYS_IOCTL_H=1 > -DTCL_SHLIB_EXT=\".so\" /home/abhishek/NS-2/ns-allinone-2.1b9a/tcl8.3.2/uni > x/../unix/tclAppInit.c > cc -rdynamic tclAppInit.o > -L/home/abhishek/NS-2/ns-allinone-2.1b9a/ns-2.1b9a > /indep-utils/cmu-scen-gen/setdest -ltcl8.3 -ldl -lieee > -lm -lc \ > -Wl,-rpath,/usr/local/lib -o tclsh > > [root@localhost setdest]# ./setdest > bash: ./setdest: No such file or directory > > ----------- > > Please advice. > > Thanks & Regards, > Abhishek > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- Xuan Chen USC/ISI From xuanc@ISI.EDU Sun Feb 2 08:55:06 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 08:55:06 2003 Subject: [ns] Wireless Simulation In-Reply-To: <20030202160930.77214.qmail@web10906.mail.yahoo.com> Message-ID: YOu might have already noticed the difference in node configuration between other wireless simulation script and wireless-mitf. To get rid of the warning, you need to create channel object rather than just specify channel type. hope it helps, -chen On Sun, 2 Feb 2003, Abhishek Patil wrote: > > > Hi Bhaskar, > > Thank for the reply. > > I am testing out the code that came with the NS (2.1b9a) installation. I > have not yet started testing my own code. So, is there something in the > sample code that come with NS that has some problem that i need to correct? > > Regards, > Abhishek > > --- Bhaskar Anepu wrote: > > > > > > One reason for segmentation fault might be that you > > are dividing something with zero somewhere in the > > simulation. Another reason might be with the memory > > locations. That is when your code tries to mess up > > with them. Thanks. > > > > Regards, > > Bhaskar > > > > --- Abhishek Patil wrote: > > > > > > > > > Hi All, > > > > > > I made the relevent changes to eliminate the > > > -channel warning. > > > I couldnt understand the reason for doing it. I read > > > the note in the file > > > 'wireless-mitf.tcl' regarding this. But it doesnt > > > explain much. Can > > > somebody explain it to me please. > > > --------------- > > > [root@localhost ex]# ns wireless-shadowing-test.tcl > > > num_nodes is set 2 > > > warning: Please use -channel as shown in > > > tcl/ex/wireless-mitf.tcl > > > Starting Simulation... > > > NS EXITING... > > > -------------- > > > > > > > > > Some of the simulations were giving me a > > > segmentation fault. What can be > > > the reason?: > > > ----------------- > > > [root@localhost ex]# ns wireless.tcl > > > num_nodes is set 50 > > > Loading connection pattern... > > > Loading scenario file... > > > Load complete... > > > Starting Simulation... > > > Segmentation fault > > > ------------------- > > > > > > > > > Thanks & Regards, > > > Abhishek Patil > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Mail Plus - Powerful. Affordable. Sign up > > > now. > > > http://mailplus.yahoo.com > > > > > > > > > ===== > > MobNets, > > The Mobile Networking group of > > WINLAB, > > RUTGERS, the st univ of NJ. > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- Xuan Chen USC/ISI From nicolas@cs.virginia.edu Sun Feb 2 09:10:02 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Sun Feb 2 09:10:02 2003 Subject: [ns] cmu-scene-gen using setdest In-Reply-To: <20030202165911.4863.qmail@web10902.mail.yahoo.com> References: <20030202165911.4863.qmail@web10902.mail.yahoo.com> Message-ID: On Sun, 2 Feb 2003, Abhishek Patil wrote (in private correspondance at my request): > I have attached the output of the makefile > > cc [...] ns-allinone-2.1b9a/tcl8.3.2/unix/../generic/regcomp.c > [etc] ????? This describes the compilation process of tclsh (and it is working, as far as I can tell), not setdest. Are you sure you are in the right directory? Go in ns-2.1b9a/indep-utils/cmu-scen-gen/setdest and run "make" there. -- Nicolas Christin Ph.D. Candidate, University of Virginia, Computer Science http://www.cs.virginia.edu/~nicolas From xuanc@ISI.EDU Sun Feb 2 09:20:02 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 09:20:02 2003 Subject: [ns] WRED Implementation In-Reply-To: Message-ID: It does, please refer to ns manula chapter 9 for details. Thanks. On Sat, 1 Feb 2003 gagutierrez@ISA.com.co wrote: > > Hi, all > > Do you know if exisist some WRED-Diffserv implementation in ns? > > > Thanks > > German > -- Xuan Chen USC/ISI From xuanc@ISI.EDU Sun Feb 2 09:20:12 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 09:20:12 2003 Subject: [ns] DiffServ question In-Reply-To: Message-ID: Yes, you can use -1 to present any host. On Sat, 1 Feb 2003, Yasser A. Lotfy wrote: > > Good day, > I am trying to create policy entry using addPolicyEntry like this: > $qEdgeCore($e) addPolicyEntry [$mobileNode($m) id] \ > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > > the problem is that the more nodes I ad, the bigger the table gets, then I have to go to ~/ns/diffserv/dsPolicy.h and increase the MAX_POLICY_ENTRY beyond the usual 20 which berings the running speed of ns significantly down. > > Is there any generic policy entry to a group of nodes or to all nodes like for example: > > $qEdgeCore($e) addPolicyEntry -1 \ > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > To indicate that $coreNode($c) should acept any traffic (coming from any source) and provide QoS based on the DSCP of the traffic? > > Also can you direct me to how to mark traffic with correct DSCP at source nodes? > > Appreciate your help > > Yasser > carleton University > > > > _____________________________________________________________ > Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. > http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus > -- Xuan Chen USC/ISI From xuanc@ISI.EDU Sun Feb 2 09:45:02 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 09:45:02 2003 Subject: [ns] TDMA MAC protocol in NS-2 In-Reply-To: <20030108171851.94619.qmail@web13707.mail.yahoo.com> Message-ID: On Thu, 9 Jan 2003, seet shirmin wrote: > > Hi Sir, > I tried to run the MAC-TDMA protocol in NS-2. Scenario was a 3 straight node sending from Node 0 to Node 2. > Current settings in MAC-TDMA C++ codes: > slot_packet_len = 1500 > max_node_num = 64 > MY queries: > 1) When i change slot_packet len to a smaller number, the throughput will be higher than the original one?? I think the reason is that you actually reduce the length of a TDMA period, which will increase throughput---you can do a simple calculation on that. > 2) There is no change in throughput graph if i assign different value for max_node_num?? Well, since you still just have 3 nodes, how can max_node_num variable affect performace? (may be a little bit, but not much...) hope it helps, -chen > Why does the slot_packet _len affects the throughput but the max_node_num does not? > Please advise...thanks a lot > >  Yahoo! Travel > - Get the latest travel deals in town! -- Xuan Chen USC/ISI From xuanc@ISI.EDU Sun Feb 2 09:55:05 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 09:55:05 2003 Subject: [ns] wireless sensor networks In-Reply-To: <20030131043910.16575.qmail@web40911.mail.yahoo.com> Message-ID: I guess you can post your question to the list directly, there are quite many people doing sensor network research now...;) In terms of general support, ns has integrated directed diffusion, and smac, etc. You may find the ns manual or the sample scripts under ns/tcl/ex or ns/tcl/test helpful. -chen On Thu, 30 Jan 2003, tahir mahjabeen wrote: > > Dear users > If any one works over wireless sensor netwoks > proocols please reply > I need help > waiting.... > thanx > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- Xuan Chen USC/ISI From xuanc@ISI.EDU Sun Feb 2 10:10:05 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Sun Feb 2 10:10:05 2003 Subject: [ns] I want to ask smth In-Reply-To: <000801c2c91e$b1ec2400$2e210a0a@LAPTOP> Message-ID: I am not sure about your meaning of "correct function", however I am pretty sure that a good software (like ns and nam or MS office) should be portable to different platforms (with technical and support effort, of course) despite its original development environment. If "correct functions" means all test suite should pass, then I agree that there are still quite some work for us to figure out on win32. However, please keep in mind, a test suite failure does not mean that ns or nam is not functioning correctly. This is because quite some failures are caused by some trivial problems, such as formatting, etc. So, I am still quite confident about the correctness of ns and nam on win32 platform even some test suites fail. On the other hand, we are trying our best to support ns and nam for win32 platform. In the mean while, we consistently seeking for helps and suggestions to this end. As you may noticed that there are quite some discussion on cygwin recently, you are welcome go that way to make ns and nam work "correctly" on windows---we are fixing some output problems to make sure that most test suites will pass on cygwin. -chen On Fri, 31 Jan 2003, Ilker BEKMEZCI wrote: > Neither ns-2 nor nam-1 is developed on (nor for) the win32 platform. We can > only guarantee that they compile on windows, but not their correct functioning. > > > -- Xuan Chen USC/ISI From prabha@wam.umd.edu Sun Feb 2 10:55:04 2003 From: prabha@wam.umd.edu (Prabha Ramachandran) Date: Sun Feb 2 10:55:04 2003 Subject: [ns] Data Packet's sink for AODV. Message-ID: Hi, When a (data)packet is received at the destination, in which layer is it consumed, i.e where is the sink? I looked at the mac-802.11.{h,cc}, ll.{h,cc} and phy.{h,cc} for AODV. But I could not find the sink. Please help. Thanks Prabha From tianq@ecn.purdue.edu Sun Feb 2 10:55:17 2003 From: tianq@ecn.purdue.edu (Qingjiang Tian) Date: Sun Feb 2 10:55:17 2003 Subject: [ns] HELP about wireless trace file Message-ID: Dear all, following is oneline from my simulation trace file: D 13.372164380 _5_ IFQ ARP 4 cbr 240 [0 0 5 800] [energy 499.986694] ------- [5:0 10:1 32 10] [0] 0 0 i can say that node 5 drop cbr packet 4 due to "ARP".but what does "ARP".the ns manual says that "DROP_IFQ_ARP_FULL,i.e. dropped by ARP"?can any one explain it to me in more detail what it really mean? since i don't wanna any packet to be dropped. how can i modify my simulation paremeters to prevent such dropping? thanks a lot for your help. if you can recommend some reference,that would be great. ===== MobNets, The Mobile Networking group of WINLAB, RUTGERS, the st univ of NJ. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From fontas@ece.gatech.edu Sun Feb 2 12:25:01 2003 From: fontas@ece.gatech.edu (Xenofon Christos Dimitropoulos) Date: Sun Feb 2 12:25:01 2003 Subject: [ns] BGP modules Message-ID: <2109.24.99.30.151.1044217431.squirrel@secure2.ece.gatech.edu> Hi all, I am working on a BGP implementation for ns-2. In particular I am trying to incorporate GNU Zebra bgpd into ns. The implementation is almost ready ( some clean up and testing is needed ), Soon ( 1-2 weeks ) I would be happy to make it available to anyone interested. Fontas From sirahman@stanford.edu Sun Feb 2 13:35:02 2003 From: sirahman@stanford.edu (Shahriar Rahman) Date: Sun Feb 2 13:35:02 2003 Subject: [ns] LAN Bridging simulation(s) in NS-2 In-Reply-To: <2109.24.99.30.151.1044217431.squirrel@secure2.ece.gatech.edu> Message-ID: Hi, I am doing some research in the area and need some empirical information on performance of bridging algorithms, such as convergence and re-convergence of the spanning tree in the STP protocol, etc. I would need to know the following information: 1. Is there any NS-2 simulation(s) of IEEE 802.1d or 802.1w spanning tree protocols available? Has anyone looked into them before? 2. Is there any NS-2 simulation(s) of LAN/VLAN bridging available? Thanks in advance for any useful information/pointers. _regards_ Shahriar From knadkarn@vt.edu Sun Feb 2 14:45:03 2003 From: knadkarn@vt.edu (Ketan Nadkarni) Date: Sun Feb 2 14:45:03 2003 Subject: [ns] function call in a tcl script Message-ID: <3E42BAAF@zathras> Hi I have a function in my tcl script: Agent/TCP instproc test {p1 p2} { ................ ................ } All i want to do is check if this function is called (this function is some times called and some times isn't). e.g if { above function is called } { do smth } else { do smth else } How do I do this? I'd greatly appreciate any help... Regards, Ketan From nicolas@cs.virginia.edu Sun Feb 2 15:00:04 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Sun Feb 2 15:00:04 2003 Subject: [ns] function call in a tcl script In-Reply-To: <3E42BAAF@zathras> References: <3E42BAAF@zathras> Message-ID: On Sun, 2 Feb 2003, Ketan Nadkarni wrote: > I have a function in my tcl script: > > Agent/TCP instproc test {p1 p2} { > ................ > ................ > > } > > All i want to do is check if this function is called (this function is some > times called and some times isn't). Where do you want to do the check? In Tcl or in C++? For C++, you could turn on a flag at the entry point of your function, and turn it off at the exit point. You can then bind the flag to a C++ variable. -- Nicolas From gp@usabusiness1.com Sun Feb 2 16:20:03 2003 From: gp@usabusiness1.com (Guillermo Paez) Date: Sun Feb 2 16:20:03 2003 Subject: [ns] Multiplique sus negocios con USA... Message-ID: <200302030017.h130HnD27985@gamma.isi.edu> Beneficios de su

Beneficios de su

Dirección Comercial o

Shipping Address en USA

 

 

 

·          Es el primer paso para hacer negocios en USA, facilita a proveedores el envío de correspondencia, catálogos, muestras y mercaderías.

 

·          Hace factibles sus compras con tarjetas de crédito por Internet al declararla como su shipping address.

 

·          Con nosotros usted obtiene una  Street Addressno un PO Box, es decir recibimos desde pequeños paquetes a cajas y palets de carga sin problemas de negativas o retornos al proveedor típicos de un PO Box.

 

·          Notificamos vía e mail  lo que ha llegado para que usted decida el medio de envío: Courier, carga, correo, retiro personal, etc.

 

·          Servicios adicionales: al mantener su dirección con nosotros tiene preferencia para cotizaciones, gestiones, tarifas y oferta de liquidaciones que pasan por nuestras manos, su membresía es un instrumento para el éxito de sus negocios con USA.

 

Costo?

 

Dirección personal:

US $99.00 anuales

 

Dirección corporativa:

hasta 5 miembros por:

 

US $190.00 anuales

 

Suscríbase aquí

 

Visite nuestro website para información de otros servicios que ofrecemos para multiplicar sus negocios.

 

www.USABusiness1.com

 

Atentamente

Guillermo Paez

gp@usabusiness1.com

 

envie todas sus compras en USA a

 

Su nombre / USABusiness 1

10369 NW 41 Street bay 115

Miami, FL 33178

From mingli@utdallas.edu Sun Feb 2 18:45:03 2003 From: mingli@utdallas.edu (Ming Li) Date: Sun Feb 2 18:45:03 2003 Subject: [ns] problem installing EDCF code Message-ID: Hi all, I am trying to install the EDCF code downloaded from Qiang Ni's website. However, I was not be able to successfully compile the code using "make install". The error messages are as follows: undefined reference to TCLObject:....... There are a lot of such messages. It seems that the TCL library was not correctly binded. Can anyone tell me what the problem might be? I have set the LD_LIBRARY_PATH, TCL_LIBRARY, and NS in .bash_profile. Thanks, ming From kikujo000@yahoo.co.in Sun Feb 2 19:15:06 2003 From: kikujo000@yahoo.co.in (=?iso-8859-1?q?kiran=20kumar=20joseph?=) Date: Sun Feb 2 19:15:06 2003 Subject: [ns] New multicast protocol Message-ID: <20030203030606.45875.qmail@web8007.mail.in.yahoo.com> Hi, I am a trying to simulate a new multicast member join protocol incooperating the QoS satisfaction.I am planning to do it using the NS2.9 simulator. My project description goes like this.I am trying to do over Core Based Trees.When a new node tries to join the group it sends a JOIN message to the network.The systems(in the required group) getting this request (they should be in the TTL level of the packet) will send a reply like packet which collect the link details on its way back to the new member.So the new member can choose the best path from among the available paths. So my request to you is to suggest a version suitable for this purpose and I expect help from you in implementing this. kiran ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From rctornero@hotmail.com Mon Feb 3 05:15:14 2003 From: rctornero@hotmail.com (ruben tornero cruzatt) Date: Mon Feb 3 05:15:14 2003 Subject: [ns] [bug] invalid tcl format Message-ID: <200302030433.h134X3V08735@www.isi.edu> [Bug Report] ----------------------------- Category: Other Package: nam nam-1.0a11a. OS: LINUX Environment Variables: LD_LIBRARY_PATH= TCL_LIBRARY= TK_LIBRARY= ----------------------------- Description: Description of Problem: when I run my program a message appear about a invalid tcl format, which said that I'm using an older version THAN nam-1.0a11a. BUT I'm using that version running over RED HAT 8.0. How Easily Reproducible: every time I run in NAM Steps to Reproduce: 1. I put ./nam , the route and name of the file 2. The message appear 3. The program run but it said I can't run the xgrafic. Actual Results: My program simulate the sistem. Expected Results: The program run but it said I can't run the xgrafic, I don't know what is happening, I'm novice. From ghiddink@agere.com Mon Feb 3 05:15:47 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Mon Feb 3 05:15:47 2003 Subject: [ns] range of base station Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97C5@nl0030excuag01.agere.com> Hi, RXThresh models the receiver sensitivity. A lower threshold makes the receiver correctly receive signals that otherwise would be too low. So if you set the receiver to a lower threshold, then your range (for traffic from any node to this node) increases. Apparently for most users, the model of RXTresh, transmit power level, receiver sensitivity etcetera is a bit too detailed. Maybe ns2 needs another model that is a bit simpler and only has one parameter: range. Yeah I know "if you desire such a feature then implement it and submit a patch". Regards, Gerrit > -----Original Message----- > From: Bhaskar Anepu [mailto:mobnets@yahoo.com] > Sent: Friday, January 31, 2003 10:12 PM > To: Qingjiang Tian; Veronica Vanni > Cc: ns-users@ISI.EDU > Subject: Re: [ns] range of base station > > > > > RXThresh_ does not effect the range of your mobile > node. It is the transmit power (pt_) that does. > Following are some values > > Phy/WirelessPhy set Pt_ 8.5872e-4 ;# 40m tx range > Phy/WirelessPhy set Pt_ 7.214e-3 ;# 100m > Phy/WirelessPhy set Pt_ 0.2818 ;# 250m > > If you want to make it operate at 1000m you might need > to set the corresponding value. Thank You. > > Regards, > Bhaskar > > --- Qingjiang Tian wrote: > > > > > > > Hi All, > > > please help me, How can I change the range of base > > station? > > > I want that the range is 1000m, but i tried to > > insert the follwing command in my script: > > > Phy/WirelessPhy set RXThresh_ 1.42681e-12 > > > but the range is still 250m!! > > > I tried to change this value in ns-default.tcl, > > but the range is still 250m!! > > > If I don't resolve this problem, I can't to > > continue my work and I have a deadline very soon. > > > Thank you, Veronica > > yeah, i have the similar problem. in my simulation, > > i try to control the > > transmission range of mobilenode.so if any one can > > figure out how to > > control it, please kindly let us know. > > btw, how can you know the range is still 250m? > > thanks > > > > > ===== > MobNets, > The Mobile Networking group of > WINLAB, > RUTGERS, the st univ of NJ. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > From osanz@tiservinet.es Mon Feb 3 05:15:58 2003 From: osanz@tiservinet.es (Oliver Sanz) Date: Mon Feb 3 05:15:58 2003 Subject: [ns] Suscription to mail list Message-ID: <002501c2cb5b$1f49d4f0$77d2a8c0@sac202> This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C2CB63.80CE26B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have the user olivers@mat.upc.es I want to change it by = osanz@tiservinet.es. Thanks ------=_NextPart_000_0022_01C2CB63.80CE26B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have the user olivers@mat.upc.es I want to = change it by=20 osanz@tiservinet.es.
=
 
Thanks
------=_NextPart_000_0022_01C2CB63.80CE26B0-- From bourgett@panasonic.de Mon Feb 3 05:16:27 2003 From: bourgett@panasonic.de (Alexander Bourgett) Date: Mon Feb 3 05:16:27 2003 Subject: [ns] Need overall design concept clarification of NS2 References: <3E3A8AF3.D40B21DB@optonline.net> <3E3AB0D3.1070204@panasonic.de> <3E3ACDA5.8B9F4C3D@optonline.net> Message-ID: <3E3E32FA.6040400@panasonic.de> Frank wrote > "What you need to implement, is the functionality that gathers > the information applied to this appdata_ variable (is it called this > way) in the packet header. Maybe this is already implemented in AppData > class for "real data".", well I have the data, I can but it in a buffer > instead of class members, but I have no clue how to send and receive it, > LOL!!!! Do I create a bogus protocol header and just stuff it all in there? > How do you send raw data instead through a bogus protocol header (not even > sure I can that to work either, LOL), the right way? As packets are events, and ns is a event driven simulator I don't see how raw data should be send. You need packets to trigger your agent actions. As I understand the concept of ns2, traffic is everytime a number of packets, mostly containing no user payload. By default all packet headers that are defined in ns-packets.tcl and packet.h are send with every packet. For example sending a RTP packet in ns2 means filling only the RTP header part of a packet with appropriate data, and does not mean to send only the RTP header. Even the UDP agent in ns2 uses parts of the RTP header (for sending trace information ??). For sending user data the only difference, on agent level, is to not only set a specific header but even to fill the data into the data_ var in the packet. This functionality must be implemented in your Agent. Therefore you must extend the recv() or send() function of your Agent, or use an agent that allready has this done. Next, you need a way your application can handover the user data to the agent. Your app builds a data array and calls the recv() or send() function with a reference to the data array. As said above the agent then puts the data in the data field of the packets and sends them. For more detailed information on this you might see chapter 12 and 35 of ns documentation. Alex. From ramla_ahmad@yahoo.com Mon Feb 3 05:16:40 2003 From: ramla_ahmad@yahoo.com (Ramla Ahmad) Date: Mon Feb 3 05:16:40 2003 Subject: [ns] regarding results Message-ID: <20030203092920.10620.qmail@web9503.mail.yahoo.com> --0-535638889-1044264560=:9163 Content-Type: text/plain; charset=us-ascii hi im implementing wavelength assignment algorithms using OWns on top of NS-2 (ns-allinone2.1b6) my problem is that when i try to rrun the simulations at high traffic the simulator keeps on with the processing and does not produce any result. it used to work fine before. i havent made any changes in the simulator. i am not very good at computers so i wanna know if anyone has any idea abt that. thanx ramla --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-535638889-1044264560=:9163 Content-Type: text/html; charset=us-ascii

hi

im implementing wavelength assignment algorithms using OWns on top of NS-2 (ns-allinone2.1b6) my problem is that when i try to rrun the simulations at high traffic the simulator keeps on with the processing and does not produce any result. it used to work fine before. i havent made any changes in the simulator.

i am not very good at computers so i wanna know if anyone has any idea abt that.

thanx

ramla



Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-535638889-1044264560=:9163-- From davosnitti@katamail.com Mon Feb 3 05:16:55 2003 From: davosnitti@katamail.com (Davide Oscar Nitti) Date: Mon Feb 3 05:16:55 2003 Subject: [ns] Remember! There's a fast procedure to compile ns-2/nam-1 on Win32 Platforms Message-ID: <127.0.0.1+Vi1cqfse5qLWDSUIW4TMe4@all-1.inet.it> Hi all, I monthly send this e-mail at ns-users mailing list. I developed some procedures to quickly compile ns-2/nam-1 on Win32 Platforms (now also for WinXp). It is described at: http://members.fortunecity.it/davosnitti/ns/howtocompile/en/index.htm The Faq is at http://members.fortunecity.it/davosnitti/ns/faq.htm : here there are very useful considerations for Windows users! Other useful informations, such links to documentation for Ns-Nam, Tcl-Tk and OTcl, are indicated at: http://members.fortunecity.it/davosnitti/ns/index.htm Bye, Davide Oscar Nitti Note: if you navigate in my website, you will see some bunners appear. Unfortunately, this is the condition I was due to accept for having free webspace. From veronicavanni@interfree.it Mon Feb 3 05:17:08 2003 From: veronicavanni@interfree.it (Veronica Vanni) Date: Mon Feb 3 05:17:08 2003 Subject: [ns] range of base station References: <20030131211229.57217.qmail@web40601.mail.yahoo.com> Message-ID: <004601c2cb75$8b766700$810516ac@Veronica> Thank you for your help. If I want operate at 1000m I must change Pt with the right value, this is result of the TwoRayGround's formula, but in this formula how much is Pr? Vero ----- Original Message ----- From: "Bhaskar Anepu" To: "Qingjiang Tian" ; "Veronica Vanni" Cc: Sent: Friday, January 31, 2003 10:12 PM Subject: Re: [ns] range of base station > > > RXThresh_ does not effect the range of your mobile > node. It is the transmit power (pt_) that does. > Following are some values > > Phy/WirelessPhy set Pt_ 8.5872e-4 ;# 40m tx range > Phy/WirelessPhy set Pt_ 7.214e-3 ;# 100m > Phy/WirelessPhy set Pt_ 0.2818 ;# 250m > > If you want to make it operate at 1000m you might need > to set the corresponding value. Thank You. > > Regards, > Bhaskar > > --- Qingjiang Tian wrote: > > > > > > > Hi All, > > > please help me, How can I change the range of base > > station? > > > I want that the range is 1000m, but i tried to > > insert the follwing command in my script: > > > Phy/WirelessPhy set RXThresh_ 1.42681e-12 > > > but the range is still 250m!! > > > I tried to change this value in ns-default.tcl, > > but the range is still 250m!! > > > If I don't resolve this problem, I can't to > > continue my work and I have a deadline very soon. > > > Thank you, Veronica > > yeah, i have the similar problem. in my simulation, > > i try to control the > > transmission range of mobilenode.so if any one can > > figure out how to > > control it, please kindly let us know. > > btw, how can you know the range is still 250m? > > thanks > > > > > ===== > MobNets, > The Mobile Networking group of > WINLAB, > RUTGERS, the st univ of NJ. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > From kshegde@mufasa.cadl.iisc.ernet.in Mon Feb 3 05:17:29 2003 From: kshegde@mufasa.cadl.iisc.ernet.in (Krishnamurthy Hegde) Date: Mon Feb 3 05:17:29 2003 Subject: [ns] how to connect mcast in wireless node in simmulation script. Message-ID: hello all, I want one help please thank you Krishnamurthy Hegde Project Trainee CADL SERC,ST IISC lab IISC Bangalore - 12 off : 3600175(0ff) From nsuser2001@yahoo.com Mon Feb 3 06:15:02 2003 From: nsuser2001@yahoo.com (Aniruddha Bharadwaj) Date: Mon Feb 3 06:15:02 2003 Subject: [ns] TTL again Message-ID: <20030203141305.89826.qmail@web21102.mail.yahoo.com> I asked following 2 questions 2 days back and waiting desperately for the answers. PLease Please answer about TTL problem. HI All, I tried to use Network Simulator to implement some algorithms. Would you please help me on the following problems? 1. Cross traffic How to generate random size and random interval cross traffic packets by using TCL and Network Simulator? I used Pareto ON/OFF UDP flows to simulate the cross traffic. But it doesn't work and I don't know how to setup the random size. 2. How to setup TTL for UDP packet? I tried to setup the TTL (time to live) value of UDP packet: set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 1000 $cbr0 set interval_ 1 $cbr0 set ttl_ 1 But, it doesn’t work. This UDP packet still goes to the node 2 and node 3 instead of stopping at node 1 and sending ICMP packet back. Thanks for your help in advance. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From luciana.martins@brasiltelecom.com.br Mon Feb 3 06:45:03 2003 From: luciana.martins@brasiltelecom.com.br (luciana.martins@brasiltelecom.com.br) Date: Mon Feb 3 06:45:03 2003 Subject: [ns] Slot Release Timer - Gprs - HELP!!!!!! Message-ID: This is a multipart message in MIME format. --=_alternative 0050C9B083256CC2_= Content-Type: text/plain; charset="us-ascii" Hi users ! I am simulating GPRS module by Richa Jain. On "mac-gprs.h" was implemented a Slot Release Mechanism for GPRS MS. If the IFQ of the MS is empty and no packet is transmitted or received for four TDMA frames while the MS is holding a channel, it initiate a resource_release. And I am trying to know how to modify the value of the release timer. Can somebody help me ? Please !! Thank you. --=_alternative 0050C9B083256CC2_= Content-Type: text/html; charset="us-ascii"
Hi users !
I am simulating GPRS module by Richa Jain.
On "mac-gprs.h" was implemented a Slot Release Mechanism for GPRS MS. If the IFQ of the MS is empty and no packet is transmitted or received for four TDMA frames while the MS is holding a channel, it initiate a resource_release.
And I am trying to know how to modify the value of the release timer.
Can somebody help me ? Please !!
Thank you.

--=_alternative 0050C9B083256CC2_=-- From veronicavanni@interfree.it Mon Feb 3 07:45:03 2003 From: veronicavanni@interfree.it (Veronica Vanni) Date: Mon Feb 3 07:45:03 2003 Subject: [ns] gprs example Message-ID: <007101c2cb9a$9836b740$810516ac@Veronica> This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C2CBA2.F9AD2650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, where can I find an tcl script that use gprs? Can anyone send me some examples? Thanks in advance Vero ------=_NextPart_000_006E_01C2CBA2.F9AD2650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
where can I find an tcl script that use = gprs?
Can anyone send me some = examples?
Thanks in advance = Vero
------=_NextPart_000_006E_01C2CBA2.F9AD2650-- From nicolas@cs.virginia.edu Mon Feb 3 07:50:03 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Mon Feb 3 07:50:03 2003 Subject: [ns] Today's snapshot compilation woes Message-ID: Hi, If you're not using today's (Feb 3, 2003) snapshot, read no further. Today's snapshot doesn't compile under compilers older than gcc-3. This is entirely my fault - I submitted a patch for Cygwin that breaks things in setdest/ if the compiler used is not the latest and greatest. The line #if !defined(sun) and !defined(__CYGWIN__) (in setdest.cc:13 and setdest2.cc:13) should be replaced with #if !defined(sun) && !defined(__CYGWIN__) in both setdest.cc and setdest2.cc to fix the problem. Most compilers don't understand the "and" pragma. Sorry about that, -- Nicolas From veronicavanni@interfree.it Mon Feb 3 08:25:01 2003 From: veronicavanni@interfree.it (Veronica Vanni) Date: Mon Feb 3 08:25:01 2003 Subject: [ns] noah protocol (gprs) Message-ID: <007e01c2cba0$3fa5edc0$810516ac@Veronica> This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C2CBA8.A10A0D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I downlaoded the patch for gprs, but i use ns-2.1b9 so I copied all file = of the patch in my directory, but I didn't the following files: noah.cc = and noah.h. Can someone send them? Thanks Vero ------=_NextPart_000_007B_01C2CBA8.A10A0D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
I downlaoded the patch for gprs, but i = use ns-2.1b9=20 so I copied all file of the patch in my directory, but I didn't the = following files: noah.cc and noah.h. Can someone send them?
Thanks Vero
------=_NextPart_000_007B_01C2CBA8.A10A0D50-- From bourgett@panasonic.de Mon Feb 3 08:30:01 2003 From: bourgett@panasonic.de (Alexander Bourgett) Date: Mon Feb 3 08:30:01 2003 Subject: [ns] Q: How to create a new node type? Message-ID: <3E3E97DD.7010205@panasonic.de> Hi. I've got some questions concerning the creation of a new node type, let's say a new type of MobileIP wireless node for example. a) Has someone in this mailing list ever created a new node type. Something like "Node/MobileNode". I'm really confused about how this new node type gets selected by node-config. Is all necessary code therefore in ns-lib.tcl an in ns-mobilenode.tcl. Is the rest of code in ns-mip.tcl or .tcl deprecated or usefull anymore? b) How does the concept of RtModule and Adhoc routing work together? Am I right that RtModule is for wired nodes only? Maybe someone of you has some experience with this. I´ve read the appropriate chapters in the ns documentation, but somehow I don't find a real representation of it in the source code. Thanks in advance. Alex. From ccarter@cs.uiuc.edu Mon Feb 3 08:35:02 2003 From: ccarter@cs.uiuc.edu (Casey Carter) Date: Mon Feb 3 08:35:02 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA References: <1044009368.3e3a519878bad@nao.disca.upv.es> Message-ID: <3E3E9082.7060608@cs.uiuc.edu> Analysis of the trace file (with mac trace on) reveals that this problem is due to a bug in the 802.11 mac implementation. 802.11 tries to send an RTS several times (7 times in ns2) before reporting failure. In the ns2 mac, the retry counter is reset when the mac successsfully sends or _receives_ a packet. As long as node 1 in your scenario keeps receiving packets from node 0, before it can reach seven retries, it will not report failure. My trace file shows that node 1 retries this particular RTS about 650 times between 25 and 33.13 seconds. The particular culprit is in void MAC802_11::recvDATA(Packet*); the conditional branch that cleans up CTS packets after successful reception resets ssrc_, the RTS retry counter. Anybody know why? Commenting out the line that reads ssrc_ = 0; forces the proper behavior. calafate@disca.upv.es wrote: >Hi, > >I have sent a possible bug report to the NS mailing list, but since no one was >able to give me a reply, perhaps someone in this mailing list is interested. > >Results of dozens of simulations using AODV, DSR and TORA in ns2.1b9a (2.1b8 >too) show that these protocols do not behave correctly when there are 802.11 >broken links. > >When looking at the overall results of simulations with many nodes, the effect I >describe is not evident. It is necessary to look at a single flow to see that >nodes fail to quickly detect broken links, making the re-routing process last >too long. This effect does not exist when using other protocols like OLSR or >Hello-driven AODV since they do not use link-layer info. > >The files I attach show this problem clearly in a very simple scenario > >Please help! > >Best regards, > >_________________________________________________ >Carlos Miguel Tavares de Araújo Cesariny Calafate >Polytechnic University of Valencia >e-mail: calafate@disca.upv.es >http://reptar.grc.upv.es/~calafate/ >Tel: +34 963879703 ext. 77977 >_________________________________________________ > > -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 From mobnets@yahoo.com Mon Feb 3 08:45:03 2003 From: mobnets@yahoo.com (Bhaskar Anepu) Date: Mon Feb 3 08:45:03 2003 Subject: [ns] range of base station In-Reply-To: <272DC08D5A30274C9A2707E51717E54F027B97C5@nl0030excuag01.agere.com> Message-ID: <20030203164438.29554.qmail@web40612.mail.yahoo.com> Hi Gerrit, You are right. RXThresh, CSThresh... all effect the range. But I think they do it indirectly. By this I mean, if you set your channel to operate at 11Mbps and set the Tx power so as to operate for 100m range. The receiver may receive packets even when 100m away from the transmitter but the data rate at this point might be less than 11Mbps. I do not exactly know how much each parameter effects the transmission range. Hence setting pt_ to the desired value and operating at a distance less than the expected range might be helpful. Thank You. Regards, Bhaskar ===== MobNets, The Mobile Networking group of WINLAB, RUTGERS, the st univ of NJ. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From alexh@telecom.lth.se Mon Feb 3 08:50:04 2003 From: alexh@telecom.lth.se (Ali Hamidian) Date: Mon Feb 3 08:50:04 2003 Subject: [ns] HELP about wireless trace file References: Message-ID: <3E3E9BFD.2000401@telecom.lth.se> --------------070108080309080803050304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, A packet can be dropped due to "ARP" in three ways - see arp.cc and look for "DROP_IFQ_ARP_FULL"! One likely reason can be that your cbr packet is held (buffered) while a MN is looking for the MAC address of another node (i.e. MN has sent an arprequest and it is waiting for an arpreply). If another packet comes to arp.cc before your held cbr packet is sent, the cbr packet will be dropped due to "ARP" to give place for the newly received packet (arpresolve in arp.cc): if(llinfo->hold_) { drop(llinfo->hold_, DROP_IFQ_ARP_FULL); } llinfo->hold_ = p; Hope it helps Ali Qingjiang Tian wrote: >Dear all, > following is oneline from my simulation trace file: > D 13.372164380 _5_ IFQ ARP 4 cbr 240 [0 0 5 800] [energy 499.986694] ------- [5:0 10:1 32 10] [0] 0 0 >i can say that node 5 drop cbr packet 4 due to "ARP".but what does >"ARP".the ns manual says that "DROP_IFQ_ARP_FULL,i.e. dropped by ARP"?can >any one explain it to me in more detail what it really mean? since i don't >wanna any packet to be dropped. how can i modify my simulation paremeters >to prevent such dropping? > thanks a lot for your help. if you can recommend some reference,that would be great. > > >===== >MobNets, >The Mobile Networking group of >WINLAB, >RUTGERS, the st univ of NJ. > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > > --------------070108080309080803050304 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

A packet can be dropped due to "ARP" in three ways - see arp.cc and look for "DROP_IFQ_ARP_FULL"! One likely reason can be that your cbr packet is held (buffered) while a MN is looking for the MAC address of another node (i.e. MN has sent an arprequest and it is waiting for an arpreply). If another packet comes to arp.cc before your held cbr packet is sent, the cbr packet will be dropped due to "ARP" to give place for the newly received packet (arpresolve in arp.cc):

if(llinfo->hold_) {
    drop(llinfo->hold_, DROP_IFQ_ARP_FULL);
}
llinfo->hold_ = p;


Hope it helps
Ali

Qingjiang Tian wrote:
Dear all,
following is oneline from my simulation trace file:
D 13.372164380 _5_ IFQ ARP 4 cbr 240 [0 0 5 800] [energy 499.986694] ------- [5:0 10:1 32 10] [0] 0 0
i can say that node 5 drop cbr packet 4 due to "ARP".but what does
"ARP".the ns manual says that "DROP_IFQ_ARP_FULL,i.e. dropped by ARP"?can
any one explain it to me in more detail what it really mean? since i don't
wanna any packet to be dropped. how can i modify my simulation paremeters
to prevent such dropping?
thanks a lot for your help. if you can recommend some reference,that would be great.


=====
MobNets,
The Mobile Networking group of
WINLAB,
RUTGERS, the st univ of NJ.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



--------------070108080309080803050304-- From xuanc@ISI.EDU Mon Feb 3 08:55:03 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Mon Feb 3 08:55:03 2003 Subject: [ns] Today's snapshot compilation woes In-Reply-To: Message-ID: Thanks for bringing this up, I just fixed it. Should be ok by tomorrow. Sorry for any inconvenience caused! -chen On Mon, 3 Feb 2003, Nicolas Christin wrote: > > Hi, > > If you're not using today's (Feb 3, 2003) snapshot, read no further. > > Today's snapshot doesn't compile under compilers older than gcc-3. This > is entirely my fault - I submitted a patch for Cygwin that breaks things > in setdest/ if the compiler used is not the latest and greatest. > > The line > > #if !defined(sun) and !defined(__CYGWIN__) > (in setdest.cc:13 and setdest2.cc:13) > > should be replaced with > > #if !defined(sun) && !defined(__CYGWIN__) > > in both setdest.cc and setdest2.cc to fix the problem. Most compilers > don't understand the "and" pragma. > > Sorry about that, > -- Xuan Chen USC/ISI From mistry55@hotmail.com Mon Feb 3 08:55:17 2003 From: mistry55@hotmail.com (Manesh Mistry) Date: Mon Feb 3 08:55:17 2003 Subject: [ns] ns - segmentation fault with cbr and scen....... Message-ID: HI all i have used the setdest and cbrgen commands to create my own scen and cbr files. They are created fine. I have then used them in my program wireless1.tcl (marc Grsis tutorial-wireless), but when i run the program i get a segmentation fault: ee99b4@projectpc2 scripts]$ ns test.tcl num_nodes is set 2 warning: Please use -channel as shown in tcl/ex/wireless-mitf.tcl Loading connection pattern... Loading scenario file... Starting Simulation... Segmentation fault Does anyone know what the problem is? or will i have to create my node connection and movements explicitly? Thanks Manesh! _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://messenger.msn.co.uk From fgeck@optonline.net Mon Feb 3 08:55:32 2003 From: fgeck@optonline.net (Frank) Date: Mon Feb 3 08:55:32 2003 Subject: [ns] Flush-trace problem? Message-ID: <3E3E9EA3.A6C4ACA2@optonline.net> Ok, does any one have any idea what I did wrong here? This function / procedure is the exact same code used by other code and I call it the same way. I am writing my own gents/applications, could that cause this problem? Error: ns: finish2: invalid command name "" while executing "$self info class" (procedure "" line 3) (SplitObject unknown line 3) invoked from within "$trace flush" (procedure "_o4" line 5) (Simulator flush-trace line 5) invoked from within "$ns flush-trace" (procedure "finish2" line 3) invoked from within "finish2" Finish2.tcl proc finish2 {} { global ns $ns flush-trace #puts "running nam..." #exec nam out.nam & #exec xgraph mc.tr & exit 0 } Line that calls it: $ns at $durationOfSimulation "finish2" From george.kinal@femmecomp.com Mon Feb 3 09:00:02 2003 From: george.kinal@femmecomp.com (George Kinal) Date: Mon Feb 3 09:00:02 2003 Subject: [ns] re: mglinstaller Message-ID: <3E3E5942.32731.6DA21E@localhost> This is available by anonymous public ftp at: ftp://ftp.mathworks.com/pub/tech-support/solutions/s30755/glnx86/mglinstaller G. Kinal From mobnets@yahoo.com Mon Feb 3 09:10:05 2003 From: mobnets@yahoo.com (Bhaskar Anepu) Date: Mon Feb 3 09:10:05 2003 Subject: [ns] IMP: configuration for 802.11b 11Mbps WLAN Message-ID: <20030203170926.71495.qmail@web40601.mail.yahoo.com> Hello all, Here are a set of parameters configured to make the wireless model of NS2 operate at 11 Mbps. I managed to find this on the internet after great struggle. I could obtain reasonable results with the help of these values. I apologize to the author for not able to trace his/her identity. Hope this helps most of them (like me :)) breaking their heads to simulate 11Mbps 802.11b envirnment. ->Configuration for Orinoco 802.11b 11Mbps PC card with ->22.5m range Phy/WirelessPhy set Pt_ 0.031622777 Phy/WirelessPhy set bandwidth_ 11Mb Mac/802_11 set dataRate_ 11Mb Mac/802_11 set basicRate_ 1Mb #for broadcast packets Phy/WirelessPhy set freq_ 2.472e9 #channel-13. 2.472GHz Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 5.011872e-12 Phy/WirelessPhy set L_ 1.0 Phy/WirelessPhy set RXThresh_ 5.82587e-09 If someone has any corrections to this. Please respond. Thank You. Regards, Bhaskar ===== MobNets, The Mobile Networking group of WINLAB, RUTGERS, the st univ of NJ. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From 9927107@student.ul.ie Mon Feb 3 09:35:02 2003 From: 9927107@student.ul.ie (aiden jennings) Date: Mon Feb 3 09:35:02 2003 Subject: [ns] How to create a base station?? Message-ID: <3106F19CD154D34A818258EBC4147D19570673@gabriel.ul.ie> hello, I am trying to simlate a mobile ip solution and am having problems trying to set up base stations correctly. I know this problem has been posted many times on the mailing list but I have never seen a solution to the problem that is why I am posting it once again. any help would be greatly appreciated. yours sincerely, Aiden Jennings. This is the line of my code that is creating problems: set HA [create-base-station-node 1.0.0] num_nodes is set 3 no value given for parameter "errproc" to "_o34" (Node/MobileNode add-interface line 1) invoked from within "$node add-interface $chan $prop $opt(ll) $opt(mac) $opt(ifq) $opt(ifqlen) $opt(netif) $opt(ant)" (procedure "create-dsr-bs-node" line 5) invoked from within "create-$opt(rp)-bs-node $node $id" (procedure "create-base-station-node" line 21) invoked from within "create-base-station-node 1.0.0" invoked from within "set HA [create-base-station-node 1.0.0]" (file "wireless-mip-test.tcl" line 137) From Rich Griswold Mon Feb 3 10:00:03 2003 From: Rich Griswold (Rich Griswold) Date: Mon Feb 3 10:00:03 2003 Subject: [ns] HELP about wireless trace file In-Reply-To: <200302022005.h12K56D03174@gamma.isi.edu> Message-ID: On Sun, 2 Feb 2003 Qingjiang Tian wrote: > Dear all, > > following is oneline from my simulation trace file: > > D 13.372164380 _5_ IFQ ARP 4 cbr 240 [0 0 5 800] [energy 499.986694] > ------- [5:0 10:1 32 10] [0] 0 0 > > i can say that node 5 drop cbr packet 4 due to "ARP".but what does > "ARP".the ns manual says that "DROP_IFQ_ARP_FULL,i.e. dropped by > ARP"?can any one explain it to me in more detail what it really mean? > since i don't wanna any packet to be dropped. how can i modify my > simulation paremeters to prevent such dropping? > > thanks a lot for your help. if you can recommend some reference,that > would be great. In 2.1b9a, there are three places where this trace could be generated. All are in mac/arp.cc. The first two cases are when ARP_MAX_REQUEST_COUNT is exceeded (ARP_MAX_REQUEST_COUNT is set to 3 in arp.h). The third case is when a packet is already held when ARPTable::arpresolve() is called. I do not know how to prevent this from happening. -- Richard Griswold - griswold@acm.org There are only 10 types of people who understand binary - those who do and those who don't From misstkt@yahoo.com Mon Feb 3 10:15:11 2003 From: misstkt@yahoo.com (Erica Yik) Date: Mon Feb 3 10:15:11 2003 Subject: [ns] Pipe/ Redirection to file problem In-Reply-To: <20030202002519.27802.qmail@web21104.mail.yahoo.com> Message-ID: <20030203181304.22100.qmail@web11505.mail.yahoo.com> Hi all, I wrote a script file, name sf, that run ns as follow: ... ns standard.tcl Newreno 2 - $* | tail -1 > temp_dir/nr.2 ... > sf 4 0 0 3 # 4 0 0 3 are the parameters to my standard.tcl file but it has problem redirecting the output to nr.2 when i use tail -1. if i omit the | tail -1 part and redirect the whole output to nr.2. then it works fine. do anyone know why? Thank you very much! erica __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From xbw@umich.edu Mon Feb 3 12:35:03 2003 From: xbw@umich.edu (Bowei Xi) Date: Mon Feb 3 12:35:03 2003 Subject: [ns] question about function "trace-callback" Message-ID: Dear NS users: I am new to the NS and stuck at the function "trace-callback". I only want to write the "r" and "d" traces to a file. I use a proc to do so: proc separate_tracefile {trace_line} { if { [lindex $trace_line 0] == "r" or "d"} { write $trace_line to a file } } My question is how to use trace-callback to pass single trace line into the procedure. I read the callback_demo.tcl but don't quite understand it. In the command line: $link trace-callback $ns cmd What I should put in "cmd" to do the job? Will the function work on the entire topology instead on a single link? This is urgent. Any help will be greatly appreciated. Bowei Xi From xuanc@ISI.EDU Mon Feb 3 14:10:03 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Mon Feb 3 14:10:03 2003 Subject: [ns] DiffServ question In-Reply-To: Message-ID: YOu mean packet code mark? You can decide it...looking at sample scripts under ns/tcl/ex/diffserv -chen On Mon, 3 Feb 2003, Yasser A. Lotfy wrote: > and do you know how to mark the traffic with specific DSCP? > Yasser > Carleton U > ------------------------------------------ > Yes, you can use -1 to present any host. > > On Sat, 1 Feb 2003, Yasser A. Lotfy wrote: > > > > > Good day, > > I am trying to create policy entry using addPolicyEntry like this: > > $qEdgeCore($e) addPolicyEntry [$mobileNode($m) id] \ > > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > > > > the problem is that the more nodes I ad, the bigger the table > gets, then I have to go to ~/ns/diffserv/dsPolicy.h and increase > the MAX_POLICY_ENTRY beyond the usual 20 which berings the running > speed of ns significantly down. > > > > Is there any generic policy entry to a group of nodes or to all nodes like for example: > > > > $qEdgeCore($e) addPolicyEntry -1 \ > > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > > To indicate that $coreNode($c) should acept any traffic (coming > from any source) and provide QoS based on the DSCP of the traffic? > > > > Also can you direct me to how to mark traffic with correct DSCP at source nodes? > > > > Appreciate your help > > > > Yasser > > carleton University > > > > > > > > > > > _____________________________________________________________ > Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. > http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus > -- Xuan Chen USC/ISI From srihari@seas.upenn.edu Mon Feb 3 14:10:22 2003 From: srihari@seas.upenn.edu (Srihari G Narasimhan) Date: Mon Feb 3 14:10:22 2003 Subject: [ns] power aware routing in sensor nets Message-ID: <3E3EE810.70401@seas.upenn.edu> hi all, can anyone give me some pointers on how and where i need to incorporate changes in the NS -code to make a routing protocol like DSDV or aodv power-aware ?? as in from where do i get the remaining power of nodes and where do i plug in an algo to make the routing to keep in mind the remaining power of different nodes. regards -- srihari --------------------------------------------------------------------- A ship in the harbor is safe,but thats not what ships were made for. ------------------------------------| Srihari Narasimhan | Graduate Student | Electrical & Systems Engg. | University of Pennsylvania | ------------------------------------| From Bob Blakely Mon Feb 3 15:25:02 2003 From: Bob Blakely (Bob Blakely) Date: Mon Feb 3 15:25:02 2003 Subject: [ns] Wireless Node Packet Acceptance... Message-ID: <013301c2cbda$f42500d0$2e08a8c0@technocom.com> Where, in all this code, does a wireless node determine that a packet is addressed to it? How? Regards, Bob... --------------------------------------------------- "Beer is proof that God loves us and wants us to be happy" - Benjamin Franklin From haldar@ISI.EDU Mon Feb 3 16:55:03 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Mon Feb 3 16:55:03 2003 Subject: [ns] Malicious node in ns2 - please reply In-Reply-To: <20030201064136.6119.qmail@web8203.mail.in.yahoo.com> Message-ID: On Sat, 1 Feb 2003, Ramesh Rajagopalan wrote: > > Hi! > > I want to simulate a network with one of the nodes as malicious. so i need to re configure the node. I am looking at address classifier where it is mentioned that a slot number is got from destination address. I am planning on doing some modifications. May i know which are the files i am alowed to modify? Can i change : /ns/Classifier.cc , /tcl/lib/ns-node.tcl , /ns/routing/rttable.cc . > > also, the methods rt-delete and rt-add in file rttable.cc are similar to add-route and delte-route in file ns-rtmodule.cc > > Can some one please tell me what is the difference in the procedures between these files? Also if i want only one of the nodes in the network to use this modified source code, how do i do that? the whole scenario looks complex to me. please help. The procedures in rtmodule{.cc.h} are the ones used for populating the classifier in ns. I don't think the ones in rttable are actually used. In order to make some special nodes behave differently you need to configure these nodes differently from other (non-malicious nodes). During configuration these special nodes will use the procedures (I'm assumimg add- and delete- routes) defined by you. --Padma > > thanx in advance > > Ramesh > > > Ramesh Rajagopalan > Graduate Student > Department of Electrical Engineering > Syracuse University > New York > > Ramesh Rajagopalan > Graduate Student > Department of Electrical Engineering > Syracuse University > New York > Catch all the cricket action. Download Yahoo! Score tracker -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From radoshi@stanford.edu Mon Feb 3 17:05:17 2003 From: radoshi@stanford.edu (Rushabh Doshi) Date: Mon Feb 3 17:05:17 2003 Subject: [ns] using different tcp stacks Message-ID: Hello! I'm looking into the effects of different TCP stacks on a certain scenario I'm working with. For the default stack, I set up the scenario using set tcp(1) [new Agent/TCP] set tcps(1) [new Agent/TCPSink] ... $ftp attach-agent $tcp(1) Now in order to switch to another stack, say TCP/Vegas, all I have to do is set tcp(1) [new Agent/TCP/Vegas] Is that correct? Or am I missing some furthur initializations? -Rushabh -- Rushabh Doshi [radoshi at stanford dot edu] http://nondot.org/~radoshi From haldar@ISI.EDU Mon Feb 3 17:10:04 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Mon Feb 3 17:10:04 2003 Subject: [ns] Data Packet's sink for AODV. In-Reply-To: Message-ID: The data packet would directly go to the destination transport agent/application. It would be a null agent for UDP and tcpsink for tcp connections. --Padma On Sun, 2 Feb 2003, Prabha Ramachandran wrote: > > Hi, > When a (data)packet is received at the destination, in which layer is > it consumed, i.e where is the sink? I looked at the mac-802.11.{h,cc}, > ll.{h,cc} and phy.{h,cc} for AODV. But I could not find the sink. > Please help. > Thanks > Prabha > > > > > > > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Mon Feb 3 17:20:04 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Mon Feb 3 17:20:04 2003 Subject: [ns] TTL again In-Reply-To: <20030203141305.89826.qmail@web21102.mail.yahoo.com> Message-ID: On Mon, 3 Feb 2003, Aniruddha Bharadwaj wrote: > > I asked following 2 questions 2 days back and waiting > desperately for the answers. PLease Please answer > about TTL problem. > > > HI All, > > I tried to use Network Simulator to implement some > algorithms. Would you please help me on the following > problems? > > 1. Cross traffic > How to generate random size and random interval cross > traffic packets by using TCL and Network Simulator? > I used Pareto ON/OFF UDP flows to simulate the cross > traffic. But it doesn't work and I don't know how to > setup the random size. > > 2. How to setup TTL for UDP packet? > I tried to setup the TTL (time to live) value of UDP > packet: > > set cbr0 [new Application/Traffic/CBR] > $cbr0 set packetSize_ 1000 > $cbr0 set interval_ 1 > $cbr0 set ttl_ 1 The ip_hdr has a TTL field which you should be able to use. --Padma > > But, it doesn’t work. This UDP packet still goes to > the node 2 and node 3 instead of stopping at node 1 > and sending ICMP packet back. > > Thanks for your help in advance. > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From calafate@disca.upv.es Tue Feb 4 05:15:19 2003 From: calafate@disca.upv.es (calafate@disca.upv.es) Date: Tue Feb 4 05:15:19 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA In-Reply-To: <3E3E9082.7060608@cs.uiuc.edu> References: <1044009368.3e3a519878bad@nao.disca.upv.es> <3E3E9082.7060608@cs.uiuc.edu> Message-ID: <1044292617.3e3ea409eb79e@nao.disca.upv.es> Hi Casey, I am happy someone really looked into the BUG I described. I wanted to congratulate you for your efforts since I have tested your solution and it seems to actually solve the problem for all three protocols (DSR, AODV and TORA). Even though it might look a small bug, it is not! This bug makes the results achieved with these Link Level Aware protocols innacurate, since a carefull examination of what's going on in each flow shows that what's happening is not what is expected to happend. If you have more information on how to correct this bug, please e-mail me. Best regards, Carlos Calafate UPV Spain Mensaje citado por: Casey Carter : > Analysis of the trace file (with mac trace on) reveals that this problem > > is due to a bug in the 802.11 mac implementation. 802.11 tries to send > > an RTS several times (7 times in ns2) before reporting failure. In the > ns2 mac, the retry counter is reset when the mac successsfully sends or > > _receives_ a packet. As long as node 1 in your scenario keeps receiving > > packets from node 0, before it can reach seven retries, it will not > report failure. My trace file shows that node 1 retries this particular > > RTS about 650 times between 25 and 33.13 seconds. > > The particular culprit is in void MAC802_11::recvDATA(Packet*); the > conditional branch that cleans up CTS packets after successful reception > > resets ssrc_, the RTS retry counter. Anybody know why? Commenting out > the line that reads > > ssrc_ = 0; > > forces the proper behavior. > > calafate@disca.upv.es wrote: > > >Hi, > > > >I have sent a possible bug report to the NS mailing list, but since no > one was > >able to give me a reply, perhaps someone in this mailing list is > interested. > > > >Results of dozens of simulations using AODV, DSR and TORA in ns2.1b9a > (2.1b8 > >too) show that these protocols do not behave correctly when there are > 802.11 > >broken links. > > > >When looking at the overall results of simulations with many nodes, the > effect I > >describe is not evident. It is necessary to look at a single flow to > see that > >nodes fail to quickly detect broken links, making the re-routing > process last > >too long. This effect does not exist when using other protocols like > OLSR or > >Hello-driven AODV since they do not use link-layer info. > > > >The files I attach show this problem clearly in a very simple scenario > > > >Please help! > > > >Best regards, > > > >_________________________________________________ > >Carlos Miguel Tavares de Araújo Cesariny Calafate > >Polytechnic University of Valencia > >e-mail: calafate@disca.upv.es > >http://reptar.grc.upv.es/~calafate/ > >Tel: +34 963879703 ext. 77977 > >_________________________________________________ > > > > > > > -- > Casey Carter > Casey@Carter.net > ccarter@uiuc.edu > AIM: cartec69 > > > > _________________________________________________ Carlos Miguel Tavares de Araújo Cesariny Calafate Becário de la Universidad Politécnica de Valencia e-mail: calafate@disca.upv.es http://reptar.grc.upv.es/~calafate/ Tel: +34 963879703 ext. 77977 _________________________________________________ \\\\\\\"In an open world without walls and fences who needs Windows and Gates?\\\\\\\" From killa7881@libero.it Tue Feb 4 05:15:41 2003 From: killa7881@libero.it (Emiliano Graziosi) Date: Tue Feb 4 05:15:41 2003 Subject: [ns] Help to use GDB Message-ID: <000001c2cc1e$2a71a010$afb61897@acertravelmate> This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2CC26.8C360810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, some time ago I posted a message decribing my problem and I received no response at all, but now, after solving some other problems, I absolutely have to solve it. I've downloaded the GDB 5.3 debugger, but I can't understand how to debug my tcl script. I tried with "gdb ns " but I get an error message, I also tried "gdb ns" but I can't figure out how to open the tcl script. please can you tell me how to use gdb with ns? Thank you a lot in advance! Emiliano Graziosi P.S.: Even if I know that maybe no one will answer to my problem, well I put it here again: Hi to everyone, I'm really in trouble and I hope that the NS experts will be able to help me as soon as possible because if I can't solve this problem I can't start to carry out reliable measurements! I attach the following extract of the trace file of my network simulation: h 1 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 + 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 - 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 r 1.002106 3 1 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 r 1.007113400 _4_ AGT --- 15 tcp 40 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [0 0] 1 0 s 1.007113400 _4_ AGT --- 16 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [0 0] 0 0 h 1.009109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 r 1.010109 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 h 1.010109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 + 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 - 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 r 1.012232 3 0 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 + 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 - 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 + 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 - 1.014937 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 r 1.015922 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 r 1.017628 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 r 1.025654200 _4_ AGT --- 17 tcp 1040 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [1 0] 1 0 s 1.025654200 _4_ AGT --- 19 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [1 0] 0 0 r 1.035590200 _4_ AGT --- 18 tcp 1040 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [2 0] 1 0 s 1.035590200 _4_ AGT --- 20 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [2 0] 0 0 h 1.037546 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19 r 1.038546 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19 The network topology is the following: Wired Node (ID 0) | --------------------------- LAN (ID 3) | Base Station (ID 1) Wireless Node (ID 4) Looking at the trace file you can see the tcp packet following the path: 0 -> 3, 3 -> 1 and then arrives to 4. Here the problem comes: the node 4 sends the ACK and this one follow the path: 1->3 and 3->1 (red lines) before to take the right path! Why? Is it a fault of NS or is it right?? I compared the previuos trace file with the trace file of the simulation of a wired LAN: Wired Node (ID 2)----Wired Node (ID 5) | ----------------------------------------------------LAN (ID 3) | Wired Node (ID 1)-----Wired Node (ID 4) The trace file is the following: + 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.002016 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 h 0.002016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.004046 3 2 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.006062 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.008078 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 h 0.008078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 + 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.010107 3 1 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 + 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.012123 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 . . . As you can see the packet follows the path: 4->1, 1->3, 3->2 and 5->2. The ACK sent by the node 5 follows the path: 5->2, 2->3, 3->1 and 1->4. It is obvious that the strange passage of the first kind of network topology lacks (there's not the passage 2->3 and 3->2! I'm trying to understand the reason but I really can't find it out! If you could help me I would appreciate it very much, I really need an help. ------=_NextPart_000_0001_01C2CC26.8C360810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

some= time ago I posted a message decribing my = problem and I received no response at all, but now, after solving some other = problems, I absolutely have to solve it. I’ve downloaded the GDB 5.3 debugger, = but I can’t understand how to debug my tcl script. I tried with = “gdb ns <tcl_script>” but I get an error message, I also tried = “gdb ns” but I can’t figure out how to open the tcl script… = please can you tell me how to use gdb with ns?

 

Thank you a lot in = advance!

 

Emiliano = Graziosi

 

P.S.: Even if I know = that maybe no one will answer to my problem, well I put it here = again:

 

Hi to = everyone,

I’m really in = trouble and I hope that the NS experts will be able to help me as soon as = possible because if I can’t solve this problem I can’t start to carry = out reliable measurements!

 

I attach the following = extract of the trace file of my network simulation:

 

h= 1 0 3 tcp 40 ------- 0 = 0.0.1.0 0.1.1.0 0 15
+ 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15
- 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15
r 1.002106 3 1 tcp 40 ------- 0 0.0.1.0 = 0.1.1.0 0 15
r 1.007113400 _4_ AGT  --- 15 tcp 40 [13a 5 0 800] = ------- [1:0 2049:0 31 2049] [0 0] 1 0
s 1.007113400 _4_ AGT  --- 16 ack 40 [0 0 0 0] ------- = [2049:0 1:0 32 0] [0 0] 0 0
h= 1.009109 1 3 ack 60 = ------- 0 0.1.1.0 0.0.1.0 0 16
r 1.010109 3 1 ack 60 ------- 0 0.1.1.0 = 0.0.1.0 0 16
h 1.010109 1 3 ack 60 = ------- 0 0.1.1.0 0.0.1.0 0 16
+ 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16
- 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16
r 1.012232 3 0 ack 60 ------- 0 0.1.1.0 = 0.0.1.0 0 16
h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 = 0.1.1.0 1 17
h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 = 0.1.1.0 2 18
+ 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17
- 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17
+ 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
- 1.014937 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
r 1.015922 3 1 tcp 1040 ------- 0 0.0.1.0 = 0.1.1.0 1 17
r 1.017628 3 1 tcp 1040 ------- 0 0.0.1.0 = 0.1.1.0 2 18
r 1.025654200 _4_ AGT  --- 17 tcp 1040 [13a 5 0 800] = ------- [1:0 2049:0 31 2049] [1 0] 1 0
s 1.025654200 _4_ AGT  --- 19 ack 40 [0 0 0 0] ------- = [2049:0 1:0 32 0] [1 0] 0 0
r 1.035590200 _4_ AGT  --- 18 tcp 1040 [13a 5 0 800] = ------- [1:0 2049:0 31 2049] [2 0] 1 0
s 1.035590200 _4_ AGT  --- 20 ack 40 [0 0 0 0] ------- = [2049:0 1:0 32 0] [2 0] 0 0
h= 1.037546 1 3 ack 60 = ------- 0 0.1.1.0 0.0.1.0 1 19
r 1.038546 3 1 ack 60 ------- 0 0.1.1.0 = 0.0.1.0 1 19
  =

The network topology is the following:

        = ;   

       &nbs= p;  Wired Node (ID 0)

        = ;            =     |

        = ;    --------------------------- LAN (ID 3)

        = ;            =             &= nbsp;  |

        = ;            =      Base Station (ID = 1)

 

        = ;            =     Wireless Node (ID 4)

 

Looking at the trace file you can see the tcp packet following the path: 0 -> = 3, 3 -> 1 and then arrives to 4. Here the = problem comes: the node 4 sends the ACK and this one follow the path: 1->3 and = 3->1 (red lines) before to take the right path! Why? Is it a fault of NS or is it = right??

        = ;            =             &= nbsp; 

I compared the = previuos trace file with the trace file of the simulation of a wired = LAN:

           &nbs= p;            =

            = Wired Node (ID 2)----Wired Node (ID = 5)

           &nbs= p;            = |

            = ----------------------------------------------------LAN (ID 3)

           &nbs= p;            = ;            =            = |

           &nbs= p;            = ;           = Wired Node (ID 1)-----Wired Node (ID 4)        = ;            =      

 

The trace file is the following:

 

+ 0 4 1 tcp 40 = ------- 0 0.1.0.0 0.2.0.0 0 0
- 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
r 0.002016 4 1 tcp 40 ------- 0 0.1.0.0 = 0.2.0.0 0 0
h 0.002016 1 3 tcp 40 ------- 0 0.1.0.0 = 0.2.0.0 0 0
+ 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
- 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
r 0.004046 3 2 tcp 40 ------- 0 0.1.0.0 = 0.2.0.0 0 0
+ 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
- 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
r 0.006062 2 5 tcp 40 ------- 0 0.1.0.0 = 0.2.0.0 0 0
+ 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
- 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
r 0.008078 5 2 ack 40 ------- 0 0.2.0.0 = 0.1.0.0 0 1
h 0.008078 2 3 ack 40 ------- 0 0.2.0.0 = 0.1.0.0 0 1
+ 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
- 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
r 0.010107 3 1 ack 40 ------- 0 0.2.0.0 = 0.1.0.0 0 1
+ 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
- 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
r 0.012123 1 4 ack 40 ------- 0 0.2.0.0 = 0.1.0.0 0 1
        = ;            =             &= nbsp;           &n= bsp;  .

           &nbs= p;            = ;            =            = .

           &nbs= p;            = ;            =            = .

As you can see the = packet follows the path: 4->1, 1->3, 3->2 and 5->2. The ACK sent by = the node 5 follows the path: 5->2, 2->3, 3->1 and 1->4. It is = obvious that the strange passage of the first kind of network topology lacks (there’s not the passage 2->3 and = 3->2!

 

I’m trying to understand the reason but I really can’t find it out! =

 

If you could help me I = would appreciate it very much, I really need an = help.

 

 

 

------=_NextPart_000_0001_01C2CC26.8C360810-- From maeslamy@yahoo.com Tue Feb 4 05:16:00 2003 From: maeslamy@yahoo.com (ali eslamy) Date: Tue Feb 4 05:16:00 2003 Subject: [ns] question about mns Message-ID: <20030204084602.94418.qmail@web80309.mail.yahoo.com> --0-272464838-1044348362=:94394 Content-Type: text/plain; charset=us-ascii Hello all I am working on mpls restoration property and i run mns on ns2.1b8. In below of this lines is a tcl that defines a network with MPLS nodes when I run a simulation I do not see any flow of LDP messages with their colors defined in this tcl which is the same provided in MPLS examples while I see rtproto packets moving at the begining of the simulation when it is enable. I see this problem for mohammed yassir obeid but i don't find any reply for this problem. is any person to help me ? your cincerely ali ############################################################ # # # < An example of MPLS Network > # # # # # ############################################################# set ns [new Simulator] # # Open files to write trace-data for NAM and Xgraph # set nf [open mp.nam w] $ns namtrace-all $nf set f0 [open mp0.tr w] set f1 [open mp1.tr w] set f2 [open mp2.tr w] set f3 [open mp3.tr w] set f4 [open mp4.tr w] # # Finish procedure which closes the trace file and opens Xgraph and NAM # proc finish {} { global ns nf f0 f1 f2 f3 f4 $ns flush-trace close $nf close $f0 close $f1 close $f2 close $f3 close $f4 exec nam mp.nam & exec xgraph mp0.tr mp1.tr mp2.tr mp3.tr mp4.tr -geometry 800x400 & exit 0 } # Set dynamic distance-vector routing protocol # $ns rtproto DV # # make nodes & MPLSnodes # set Node0 [$ns node] set Node1 [$ns node] $ns node-config -MPLS ON set LSR2 [$ns node] set LSR3 [$ns node] set LSR4 [$ns node] set LSR5 [$ns node] set LSR6 [$ns node] set LSR7 [$ns node] set LSR8 [$ns node] $ns node-config -MPLS OFF set Node9 [$ns node] set Node10 [$ns node] # # make links # $ns duplex-link $Node0 $LSR2 10Mb 10ms DropTail $ns duplex-link $Node1 $LSR2 1Mb 10ms DropTail $ns duplex-link $LSR2 $LSR3 1Mb 10ms DropTail $ns duplex-link $LSR3 $LSR4 1Mb 10ms DropTail $ns duplex-link $LSR4 $LSR8 1Mb 10ms DropTail $ns duplex-link $LSR2 $LSR5 1Mb 10ms DropTail $ns duplex-link $LSR5 $LSR6 1Mb 10ms DropTail $ns duplex-link $LSR5 $LSR4 10Mb 10ms DropTail $ns duplex-link $LSR6 $LSR7 1Mb 10ms DropTail $ns duplex-link $LSR6 $LSR8 1Mb 10ms DropTail $ns duplex-link $LSR7 $LSR8 1Mb 10ms DropTail $ns duplex-link $LSR7 $Node9 1Mb 10ms DropTail $ns duplex-link $LSR8 $Node10 1Mb 10ms DropTail # # configure ldp agents on all mpls nodes # for {set i 2} {$i < 9} {incr i} { set a LSR$i for {set j [expr $i+1]} {$j < 9} {incr j} { set b LSR$j eval $ns LDP-peer $$a $$b } set m [eval $$a get-module "MPLS"] $m enable-reroute "new" } # # set ldp-message clolr # $ns ldp-request-color blue $ns ldp-mapping-color red $ns ldp-withdraw-color magenta $ns ldp-release-color orange $ns ldp-notification-color yellow # Define trigger strategy, Label Distribution Control Mode # and Label Allocation and Distribution Scheme Classifier/Addr/MPLS set control_driven_ 1 Classifier/Addr/MPLS enable-on-demand Classifier/Addr/MPLS enable-ordered-control Agent/LDP set trace_ldp_ 1 Classifier/Addr/MPLS set trace_mpls_ 1 $ns use-scheduler List # Define procedure to create a CBR traffic flow and connect it to a UDP agent # proc attach-expoo-traffic { node sink size burst idle rate } { global ns set udp [new Agent/UDP] $ns attach-agent $node $udp set traffic [new Application/Traffic/Exponential] $traffic set packetSize_ $size $traffic set burst_time_ $burst $traffic set idle_time_ $idle $traffic set rate_ $rate $traffic attach-agent $udp $ns connect $udp $sink return $traffic } #Create three traffic sinks and attach them to node10 set sink0 [new Agent/LossMonitor] set sink1 [new Agent/LossMonitor] set sink2 [new Agent/LossMonitor] set sink3 [new Agent/LossMonitor] set sink4 [new Agent/LossMonitor] $ns attach-agent $Node10 $sink0 $ns attach-agent $Node10 $sink1 $ns attach-agent $Node10 $sink2 $ns attach-agent $Node10 $sink3 $ns attach-agent $Node10 $sink4 # # Create 5 traffic sources # set src0 [attach-expoo-traffic $Node0 $sink0 200 0 0 400k] set src1 [attach-expoo-traffic $Node0 $sink1 200 0 0 400k] set src2 [attach-expoo-traffic $Node0 $sink2 200 0 0 400k] set src3 [attach-expoo-traffic $Node1 $sink3 200 0 0 400k] set src4 [attach-expoo-traffic $Node1 $sink4 200 0 0 400k] # # Create a TCP agent and connect it to an application like FTP or Telnet, which # generates the data # set totalpkt 0 proc record {} { global sink0 sink1 sink2 sink3 sink4 f0 f1 f2 f3 f4 totalpkt set ns [Simulator instance] #Set the time after which the procedure should be called again set time 0.005 #How many bytes have been received by the traffic sink? set bw0 [$sink0 set bytes_] set bw1 [$sink1 set bytes_] set bw2 [$sink2 set bytes_] set bw3 [$sink3 set bytes_] set bw4 [$sink4 set bytes_] #Get the current time set now [$ns now] #Calculate the bandwidth (in MBit/s) and write it to the file puts $f0 "$now [expr $bw0/$time*8/1000000]" puts $f1 "$now [expr $bw1/$time*8/1000000]" puts $f2 "$now [expr $bw2/$time*8/1000000]" puts $f3 "$now [expr $bw3/$time*8/1000000]" puts $f4 "$now [expr $bw4/$time*8/1000000]" #Reset the bytes_ values on the traffic sink $sink0 set bytes_ 0 $sink1 set bytes_ 0 $sink2 set bytes_ 0 $sink3 set bytes_ 0 $sink4 set bytes_ 0 #Re-schedule the procedure $ns at [expr $now+$time] "record" set bw0 [expr $bw0 / 200] set totalpkt [expr $totalpkt + $bw0] set bw1 [expr $bw1 / 200] set totalpkt [expr $totalpkt + $bw1] set bw2 [expr $bw2 / 200] set totalpkt [expr $totalpkt + $bw2] set bw3 [expr $bw3 / 200] set totalpkt [expr $totalpkt + $bw3] set bw4 [expr $bw4 / 200] set totalpkt [expr $totalpkt + $bw4] } proc recv-pkts {} { global totalpkt flush stdout puts "The Number of Total received packet is $totalpkt" } $ns at 0.0 "record" # # Source start # $ns at 0.1 "$src0 start" $ns at 0.1 "$src1 start" $ns at 0.1 "$src2 start" $ns at 0.1 "$src3 start" $ns at 0.1 "$src4 start" $ns at 4.6 "$src0 stop" $ns at 4.6 "$src1 stop" $ns at 4.6 "$src2 stop" $ns at 4.6 "$src3 stop" $ns at 4.6 "$src4 stop" $src0 set fid_ 1 $src1 set fid_ 2 $src2 set fid_ 3 $src3 set fid_ 4 $ns color 1 Green $ns color 2 Red $ns color 3 Blue $ns color 4 ORANGE $ns at 10.0 "recv-pkts" $ns at 10.0 "finish" # # The last line finally starts the simulation # $ns run --------------------------------- Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! --0-272464838-1044348362=:94394 Content-Type: text/html; charset=us-ascii

 Hello all

I am working on mpls restoration property and i run mns on ns2.1b8.

In below of this lines is a tcl that defines a network with MPLS nodes when I run a simulation I do not see any flow of LDP messages with their colors defined in this tcl which is the same provided in MPLS examples while I see
rtproto packets moving at the begining of the simulation when it is 
enable.

I see this problem for mohammed yassir obeid but i don't find any reply for this problem.
is any person to help me ?
your cincerely
ali
############################################################
#
#
#         < An example of MPLS Network >
#
#
#
#                                            #
#############################################################

set ns [new Simulator]

#
# Open files to write trace-data for NAM and Xgraph
#
set nf [open mp.nam w]
$ns namtrace-all $nf
set f0 [open mp0.tr w]
set f1 [open mp1.tr w]
set f2 [open mp2.tr w]
set f3 [open mp3.tr w]
set f4 [open mp4.tr w]

#
# Finish procedure which closes the trace file and opens Xgraph and NAM
#
proc finish {} {
 global ns nf f0 f1 f2 f3 f4
 $ns flush-trace
 close $nf
 close $f0
 close $f1
 close $f2
        close $f3
 close $f4
        exec nam mp.nam &   
        exec xgraph mp0.tr mp1.tr mp2.tr mp3.tr mp4.tr -geometry 800x400 &
        exit 0
}

# Set dynamic distance-vector routing protocol
#
$ns rtproto DV
#
# make nodes & MPLSnodes
#
set Node0  [$ns node]
set Node1  [$ns node]
$ns node-config -MPLS ON
set LSR2   [$ns node]
set LSR3   [$ns node]
set LSR4   [$ns node]
set LSR5   [$ns node]
set LSR6   [$ns node]
set LSR7   [$ns node]
set LSR8   [$ns node]
$ns node-config -MPLS OFF
set Node9  [$ns node]
set Node10  [$ns node]

#
# make links
#

$ns duplex-link $Node0  $LSR2  10Mb  10ms DropTail
$ns duplex-link $Node1  $LSR2  1Mb  10ms DropTail
$ns duplex-link $LSR2   $LSR3  1Mb  10ms DropTail
$ns duplex-link $LSR3   $LSR4  1Mb  10ms DropTail
$ns duplex-link $LSR4   $LSR8  1Mb  10ms DropTail
$ns duplex-link $LSR2   $LSR5  1Mb  10ms DropTail
$ns duplex-link $LSR5   $LSR6  1Mb  10ms DropTail
$ns duplex-link $LSR5   $LSR4  10Mb  10ms DropTail
$ns duplex-link $LSR6   $LSR7  1Mb  10ms DropTail
$ns duplex-link $LSR6   $LSR8  1Mb  10ms DropTail
$ns duplex-link $LSR7   $LSR8  1Mb  10ms DropTail
$ns duplex-link $LSR7   $Node9  1Mb  10ms DropTail
$ns duplex-link $LSR8   $Node10 1Mb  10ms DropTail

#
# configure ldp agents on all mpls nodes
#

for {set i 2} {$i < 9} {incr i} {
 set a LSR$i
 for {set j [expr $i+1]} {$j < 9} {incr j} {
  set b LSR$j
  eval $ns LDP-peer $$a $$b
 }
set m [eval $$a get-module "MPLS"]
$m enable-reroute "new" 

 

#
# set ldp-message clolr
#
$ns ldp-request-color       blue
$ns ldp-mapping-color       red
$ns ldp-withdraw-color      magenta
$ns ldp-release-color       orange
$ns ldp-notification-color  yellow

# Define trigger strategy, Label Distribution Control Mode
# and Label Allocation and Distribution Scheme

Classifier/Addr/MPLS set control_driven_ 1
Classifier/Addr/MPLS enable-on-demand
Classifier/Addr/MPLS enable-ordered-control

Agent/LDP set trace_ldp_ 1
Classifier/Addr/MPLS set trace_mpls_ 1

$ns use-scheduler List

# Define procedure to create a CBR traffic flow and connect it to a UDP
agent
#
proc attach-expoo-traffic { node sink size burst idle rate } {
 global ns
  
 set udp [new Agent/UDP]
 $ns attach-agent $node $udp
  
 set traffic [new Application/Traffic/Exponential]
 $traffic set packetSize_ $size
 $traffic set burst_time_ $burst
 $traffic set idle_time_ $idle
 $traffic set rate_ $rate
 $traffic attach-agent $udp

 $ns connect $udp $sink
 return $traffic
}

#Create three traffic sinks and attach them to node10
set sink0 [new Agent/LossMonitor]
set sink1 [new Agent/LossMonitor]
set sink2 [new Agent/LossMonitor]
set sink3 [new Agent/LossMonitor]
set sink4 [new Agent/LossMonitor]


$ns attach-agent $Node10 $sink0
$ns attach-agent $Node10 $sink1
$ns attach-agent $Node10 $sink2
$ns attach-agent $Node10 $sink3
$ns attach-agent $Node10 $sink4

#
# Create 5 traffic sources
#
set src0 [attach-expoo-traffic $Node0  $sink0 200 0 0 400k]
set src1 [attach-expoo-traffic $Node0  $sink1 200 0 0 400k]
set src2 [attach-expoo-traffic $Node0  $sink2 200 0 0 400k]
set src3 [attach-expoo-traffic $Node1  $sink3 200 0 0 400k]
set src4 [attach-expoo-traffic $Node1  $sink4 200 0 0 400k]

#
# Create a TCP agent and connect it to an application like FTP or Telnet,
which
# generates the data
#

 

set totalpkt 0
proc record {} {
       
        global sink0 sink1 sink2 sink3 sink4 f0 f1 f2 f3 f4 totalpkt

 set ns [Simulator instance]
 
 #Set the time after which the procedure should be called again
        set time 0.005
        
       
 

 #How many bytes have been received by the traffic sink?
        set bw0 [$sink0 set bytes_]
        set bw1 [$sink1 set bytes_]
 set bw2 [$sink2 set bytes_]
 set bw3 [$sink3 set bytes_]
 set bw4 [$sink4 set bytes_]
 
 #Get the current time
        set now [$ns now]

 #Calculate the bandwidth (in MBit/s) and write it to the file
        puts $f0 "$now [expr $bw0/$time*8/1000000]"
        puts $f1 "$now [expr $bw1/$time*8/1000000]"
        puts $f2 "$now [expr $bw2/$time*8/1000000]"
        puts $f3 "$now [expr $bw3/$time*8/1000000]"
        puts $f4 "$now [expr $bw4/$time*8/1000000]"
 
 #Reset the bytes_ values on the traffic sink
        $sink0 set bytes_ 0
        $sink1 set bytes_ 0
        $sink2 set bytes_ 0
        $sink3 set bytes_ 0
        $sink4 set bytes_ 0

 #Re-schedule the procedure
        $ns at [expr $now+$time] "record"
       
      
        set bw0 [expr $bw0 / 200]
        set totalpkt [expr $totalpkt + $bw0]
        set bw1 [expr $bw1 / 200]
        set totalpkt [expr $totalpkt + $bw1]
        set bw2 [expr $bw2 / 200]
        set totalpkt [expr $totalpkt + $bw2]
        set bw3 [expr $bw3 / 200]
        set totalpkt [expr $totalpkt + $bw3]
        set bw4 [expr $bw4 / 200]
        set totalpkt [expr $totalpkt + $bw4]

}
proc recv-pkts {} {
     global totalpkt
     flush stdout
     puts "The Number of Total received packet is $totalpkt"
}

$ns at 0.0   "record"

#
# Source start
#
$ns at 0.1   "$src0 start"
$ns at 0.1   "$src1 start"
$ns at 0.1   "$src2 start"
$ns at 0.1   "$src3 start"
$ns at 0.1   "$src4 start"

$ns at 4.6 "$src0 stop"
$ns at 4.6 "$src1 stop"
$ns at 4.6 "$src2 stop"
$ns at 4.6 "$src3 stop"
$ns at 4.6 "$src4 stop"

$src0 set fid_ 1
$src1 set fid_ 2
$src2 set fid_ 3
$src3 set fid_ 4

$ns color 1 Green
$ns color 2 Red
$ns color 3 Blue
$ns color 4 ORANGE


$ns at 10.0 "recv-pkts"
$ns at 10.0 "finish"

#
# The last line finally starts the simulation
#
$ns run

 

 

 

 

 

             

 

 

 



Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo! --0-272464838-1044348362=:94394-- From ghiddink@agere.com Tue Feb 4 05:16:18 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Tue Feb 4 05:16:18 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97CE@nl0030excuag01.agere.com> Hi, you are right, although intuitively the behavior of the MAC seems correct ("I see a CTS for my RTS, so I can reset the CW window and the retry count"), this is not according to the standard. The standard defines that the CW window and the retry counts should be reset after a succesful frame exchange. And getting a CTS for an RTS is NOT a succesful frame exchange YET. Section 9.7 of the 1999 version of 802.11 specifies that a frame exchange sequence involving RTS/CTS goes like this: {RTS - CTS - } [Frag - ACK - ] Last - ACK so the retry count and the CW window can only be reset after the station got the ACK, and not after it got the CTS. Clause 9.2.5.3 seems to support this, but the text is not explicit. Dear ns2 maintainer, can you please fix this bug in the next version of ns2? It concerns removing the lines "ssrc_ = 0" and "rst_cw()" following the comment "Our CTS got through" in recvDATA(). Another suspected bug is the behavior of the simulator in the case of the expiration of retry counts. If this happens, then the simulator resets the contention window (in retransmitDATA and retransmitRTS). I do not think this is according to the standard. Regards, Gerrit > -----Original Message----- > From: Casey Carter [mailto:ccarter@cs.uiuc.edu] > Sent: Monday, February 03, 2003 4:54 PM > To: calafate@disca.upv.es > Cc: manet@ietf.org; ns-users@ISI.EDU > Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA > > > > Analysis of the trace file (with mac trace on) reveals that > this problem > is due to a bug in the 802.11 mac implementation. 802.11 > tries to send > an RTS several times (7 times in ns2) before reporting > failure. In the > ns2 mac, the retry counter is reset when the mac > successsfully sends or > _receives_ a packet. As long as node 1 in your scenario > keeps receiving > packets from node 0, before it can reach seven retries, it will not > report failure. My trace file shows that node 1 retries this > particular > RTS about 650 times between 25 and 33.13 seconds. > > The particular culprit is in void MAC802_11::recvDATA(Packet*); the > conditional branch that cleans up CTS packets after > successful reception > resets ssrc_, the RTS retry counter. Anybody know why? > Commenting out > the line that reads > > ssrc_ = 0; > > forces the proper behavior. > > calafate@disca.upv.es wrote: > > >Hi, > > > >I have sent a possible bug report to the NS mailing list, > but since no one was > >able to give me a reply, perhaps someone in this mailing > list is interested. > > > >Results of dozens of simulations using AODV, DSR and TORA in > ns2.1b9a (2.1b8 > >too) show that these protocols do not behave correctly when > there are 802.11 > >broken links. > > > >When looking at the overall results of simulations with many > nodes, the effect I > >describe is not evident. It is necessary to look at a single > flow to see that > >nodes fail to quickly detect broken links, making the > re-routing process last > >too long. This effect does not exist when using other > protocols like OLSR or > >Hello-driven AODV since they do not use link-layer info. > > > >The files I attach show this problem clearly in a very > simple scenario > > > >Please help! > > > >Best regards, > > > >_________________________________________________ > >Carlos Miguel Tavares de Araújo Cesariny Calafate > >Polytechnic University of Valencia > >e-mail: calafate@disca.upv.es > >http://reptar.grc.upv.es/~calafate/ > >Tel: +34 963879703 ext. 77977 > >_________________________________________________ > > > > > > > -- > Casey Carter > Casey@Carter.net > ccarter@uiuc.edu > AIM: cartec69 > > > From ursbabu79" hello friends, i am using the following lines of code in MPLS rerouting.can any one please explain why the following lines are used in finding the no. of unordered packets in a record() function.what is the use of the "parse-bw" function.please send reply soon #Set the time after which the procedure should be called again set tsize [parse-bw $size] set trate [parse-bw $rate] set time [expr double($tsize)/double($trate)/8.0] Thanks in advance From B.N.babu Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From depe@dei.unipd.it Tue Feb 4 05:16:50 2003 From: depe@dei.unipd.it (De Pellegrini Francesco) Date: Tue Feb 4 05:16:50 2003 Subject: [ns] End to End delay per flow evaluation: urgent!!!! Message-ID: hi, the problem is I need to plot end-to-end delay for different routing policies, and evaluate the end-to-end delay versus the packet generation rate. This is a major headache to me, cause I cannot process the trace file, since I need to bring Net close to congestion and the packet ID are likely to wrap around. So, I should stamp in the trace the following events: a)generation of a packet at the source b) receiving of the same packet at the destination I don't have any idea at which level I am to implement it: any suggestion highly appreciated ..... Francesco From alexh@telecom.lth.se Tue Feb 4 05:17:02 2003 From: alexh@telecom.lth.se (Ali Hamidian) Date: Tue Feb 4 05:17:02 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA References: <20030204021248.37560.qmail@web40802.mail.yahoo.com> Message-ID: <3E3F9C97.4050301@telecom.lth.se> --------------040808070309090501010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Just wanted to conform what Alvin says: in my version of ns-2 (ns-2.1b9a) the line ssrc_ = 0; is NOT commented - i.e. the same as Alvin says. And that's why I told Carlos that the AODV code in ns-2.1b9a should be able to detect link breaks pretty fast. Regards Ali Alvin Valera wrote: >Hi Casey & Carlos Miguel, > >I tried Carlos Miguel's test scenarios but didn't >encounter the problem of long link layer detection >delay. When I received this e-mail, it became apparent >that in my version of ns-2 (ns-2.1b8 June 6, 2001 >release), the line > > ssrc_ = 0; > >is _NOT_ commented! That's why I couldn't duplicate >Carlos Miguel's results! > >I find this odd. Who commented out that line in the >succeeding versions and for what reason? > >Best regards, >Alvin > >--- Casey Carter wrote: > >>Analysis of the trace file (with mac trace on) >>reveals that this problem >>is due to a bug in the 802.11 mac implementation. >>802.11 tries to send >>an RTS several times (7 times in ns2) before >>reporting failure. In the >>ns2 mac, the retry counter is reset when the mac >>successsfully sends or >>_receives_ a packet. As long as node 1 in your >>scenario keeps receiving >>packets from node 0, before it can reach seven >>retries, it will not >>report failure. My trace file shows that node 1 >>retries this particular >>RTS about 650 times between 25 and 33.13 seconds. >> >>The particular culprit is in void >>MAC802_11::recvDATA(Packet*); the >>conditional branch that cleans up CTS packets after >>successful reception >>resets ssrc_, the RTS retry counter. Anybody know >>why? Commenting out >>the line that reads >> >> ssrc_ = 0; >> >>forces the proper behavior. >> >>calafate@disca.upv.es wrote: >> >>>Hi, >>> >>>I have sent a possible bug report to the NS mailing >>> >>list, but since no one was >> >>>able to give me a reply, perhaps someone in this >>> >>mailing list is interested. >> >>>Results of dozens of simulations using AODV, DSR >>> >>and TORA in ns2.1b9a (2.1b8 >> >>>too) show that these protocols do not behave >>> >>correctly when there are 802.11 >> >>>broken links. >>> >>>When looking at the overall results of simulations >>> >>with many nodes, the effect I >> >>>describe is not evident. It is necessary to look at >>> >>a single flow to see that >> >>>nodes fail to quickly detect broken links, making >>> >>the re-routing process last >> >>>too long. This effect does not exist when using >>> >>other protocols like OLSR or >> >>>Hello-driven AODV since they do not use link-layer >>> >>info. >> >>>The files I attach show this problem clearly in a >>> >>very simple scenario >> >>>Please help! >>> >>>Best regards, >>> >>>_________________________________________________ >>>Carlos Miguel Tavares de Araújo Cesariny Calafate >>>Polytechnic University of Valencia >>>e-mail: calafate@disca.upv.es >>>http://reptar.grc.upv.es/~calafate/ >>>Tel: +34 963879703 ext. 77977 >>>_________________________________________________ >>> >>> >> >>-- >>Casey Carter >>Casey@Carter.net >>ccarter@uiuc.edu >>AIM: cartec69 >> >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus - Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > --------------040808070309090501010106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Just wanted to conform what Alvin says: in my version of ns-2 (ns-2.1b9a) the line

    ssrc_ = 0;

is NOT commented - i.e. the same as Alvin says. And that's why I told Carlos that the AODV code in ns-2.1b9a should be able to detect link breaks pretty fast.

Regards
Ali


Alvin Valera wrote:
Hi Casey & Carlos Miguel,

I tried Carlos Miguel's test scenarios but didn't
encounter the problem of long link layer detection
delay. When I received this e-mail, it became apparent
that in my version of ns-2 (ns-2.1b8 June 6, 2001
release), the line

ssrc_ = 0;

is _NOT_ commented! That's why I couldn't duplicate
Carlos Miguel's results!

I find this odd. Who commented out that line in the
succeeding versions and for what reason?

Best regards,
Alvin

--- Casey Carter <ccarter@cs.uiuc.edu> wrote:
Analysis of the trace file (with mac trace on)
reveals that this problem
is due to a bug in the 802.11 mac implementation.
802.11 tries to send
an RTS several times (7 times in ns2) before
reporting failure. In the
ns2 mac, the retry counter is reset when the mac
successsfully sends or
_receives_ a packet. As long as node 1 in your
scenario keeps receiving
packets from node 0, before it can reach seven
retries, it will not
report failure. My trace file shows that node 1
retries this particular
RTS about 650 times between 25 and 33.13 seconds.

The particular culprit is in void
MAC802_11::recvDATA(Packet*); the
conditional branch that cleans up CTS packets after
successful reception
resets ssrc_, the RTS retry counter. Anybody know
why? Commenting out
the line that reads

ssrc_ = 0;

forces the proper behavior.

calafate@disca.upv.es wrote:

Hi,

I have sent a possible bug report to the NS mailing
list, but since no one was
able to give me a reply, perhaps someone in this
mailing list is interested.
Results of dozens of simulations using AODV, DSR
and TORA in ns2.1b9a (2.1b8
too) show that these protocols do not behave
correctly when there are 802.11
broken links.

When looking at the overall results of simulations
with many nodes, the effect I
describe is not evident. It is necessary to look at
a single flow to see that  
nodes fail to quickly detect broken links, making
the re-routing process last
too long. This effect does not exist when using
other protocols like OLSR or
Hello-driven AODV since they do not use link-layer
info.
The files I attach show this problem clearly in a
very simple scenario
Please help!

Best regards,

_________________________________________________
Carlos Miguel Tavares de Araújo Cesariny Calafate
Polytechnic University of Valencia
e-mail: calafate@disca.upv.es
http://reptar.grc.upv.es/~calafate/
Tel: +34 963879703 ext. 77977
_________________________________________________



--
Casey Carter
Casey@Carter.net
ccarter@uiuc.edu
AIM: cartec69



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--------------040808070309090501010106-- From ursbabu79" --=_MAILER_ATTACH_BOUNDARY_2003242165035756898537 Content-Type: text/plain; charset=us-ascii hello friends, i am getting problem while executing the following re-routing program.there is no complile errors. But when i am using "haskin" option the packets are not rerouted to alternate path.but they are simply dropped as if we used the option "drop". so please tell me the way to solve the problem.and tell me what is the difference between L3dara-driven and L3control-driven. i am sending the Tcl file attached with this mail. please send reply soon. Thanks in advance >From B.N.babu. Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy the best in Movies at http://www.videos.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! --=_MAILER_ATTACH_BOUNDARY_2003242165035756898537 Content-Type: application/octet-stream; name="reroute.tcl" Content-Transfer-Encoding: BASE64 Content-Description: reroute.tcl Content-Disposition: attachment; filename="reroute.tcl" IyMjIyMjIyMgdmFyaW91cyByZXJvdXRpbmcgbWV0aG9kcyAgIyMjIyMjIyMjIyMjIyMjCgoKcHJv YyB1c2FnZSB7IH0gewoJcHV0cyBzdGRlcnIge3VzYWdlOiBucyByZXJvdXRlLnRjbCByZXJvdXRl LW9wdGlvbgpUaGUgcmVyb3V0ZS1vcHRpb25zIGFyZSBhcyBmb2xsb3dzOiAKICAgIC0gZHJvcCAg ICAgICAgICAgICAgIAogICAgLSBtYWthbSAgICAgICAgICAgIAogICAgLSBzaW1wbGUtZHluYW1p YyAgIAogICAgLSBzaG9ydGVzdC1keW5hbWljIAogICAgICAgfQp9CgpzZXQgbnMgW25ldyBTaW11 bGF0b3JdCgpzZXQgbmEgW29wZW4gcmVyb3V0ZS50ciB3XQpzZXQgbmYgW29wZW4gcmVyb3V0ZS5u YW0gd10KJG5zIHRyYWNlLWFsbCAkbmEKJG5zIG5hbXRyYWNlLWFsbCAkbmYKc2V0IGYwIFtvcGVu IHJlcm91dGUtYncudHIgd10Kc2V0IGZzIFtvcGVuIHJlcm91dGUtc2VxLnRyIHddCnByb2MgZmlu aXNoIHt9IHsKCWdsb2JhbCBucyBuYSBuZiBmMCBmcwoJJG5zIGZsdXNoLXRyYWNlCgljbG9zZSAk bmEKCWNsb3NlICRuZgoJY2xvc2UgJGYwCgljbG9zZSAkZnMKICAgICAgICBleGVjIG5hbSByZXJv dXRlLm5hbSAmCiAgICAgICAgI2V4ZWMgeGdyYXBoIC1tIHJlcm91dGUtYncudHIgLWdlb21ldHJ5 IDgwMHg0MDAgJgoJI2V4ZWMgeGdyYXBoIC1tIC1ubCByZXJvdXRlLXNlcS50ciAtZ2VvbWV0cnkg ODAweDQwMCAmCglleGl0IDAKfQoKcHJvYyBhdHRhY2gtZXhwb28tdHJhZmZpYyB7bm9kZSBzaW5r IHNpemUgYnVyc3QgaWRsZSByYXRlfSB7CiAgICAgICAgZ2xvYmFsIG5zCgkKCXNldCBzb3VyY2Ug W25ldyBBZ2VudC9DQlIvVURQXQoJJG5zIGF0dGFjaC1hZ2VudCAkbm9kZSAkc291cmNlCgkKCXNl dCB0cmFmZmljIFtuZXcgVHJhZmZpYy9FeHBvb10KCSR0cmFmZmljIHNldCBwYWNrZXQtc2l6ZSAk c2l6ZQoJJHRyYWZmaWMgc2V0IGJ1cnN0LXRpbWUgJGJ1cnN0CgkkdHJhZmZpYyBzZXQgaWRsZS10 aW1lICRpZGxlCgkkdHJhZmZpYyBzZXQgcmF0ZSAkcmF0ZQoJCgkkc291cmNlIGF0dGFjaC10cmFm ZmljICR0cmFmZmljCgkKCSRucyBjb25uZWN0ICRzb3VyY2UgJHNpbmsKCXJldHVybiAkc291cmNl Cn0KCiMgRGVmaW5lIGEgcHJvY2VkdXJlIHdoaWNoIHBlcmlvZGljYWxseSByZWNvcmRzIHRoZSBi YW5kd2lkdGggcmVjZWl2ZWQgYnkgdGhlCiMgdHJhZmZpYyBzaW5rIHNpbmswIGFuZCB3cml0ZXMg aXQgdG8gdGhlIGZpbGUgZjAuCnNldCB0b3RhbHBrdCAwCnByb2MgcmVjb3JkIHt9IHsKICAgICAg ICBnbG9iYWwgc2luazAgZjAgdG90YWxwa3QKCQoJc2V0IG5zIFtTaW11bGF0b3IgaW5zdGFuY2Vd CgkKCSNTZXQgdGhlIHRpbWUgYWZ0ZXIgd2hpY2ggdGhlIHByb2NlZHVyZSBzaG91bGQgYmUgY2Fs bGVkIGFnYWluCiAgICAgICAgc2V0IHRpbWUgMC4wNjUKCQoJI0hvdyBtYW55IGJ5dGVzIGhhdmUg YmVlbiByZWNlaXZlZCBieSB0aGUgdHJhZmZpYyBzaW5rPwogICAgICAgIHNldCBidzAgWyRzaW5r MCBzZXQgYnl0ZXNfXQoJCgkjR2V0IHRoZSBjdXJyZW50IHRpbWUKICAgICAgICBzZXQgbm93IFsk bnMgbm93XQoJCgkjQ2FsY3VsYXRlIHRoZSBiYW5kd2lkdGggKGluIE1CaXQvcykgYW5kIHdyaXRl IGl0IHRvIHRoZSBmaWxlCiAgICAgICAgcHV0cyAkZjAgIiRub3cgW2V4cHIgJGJ3MC8kdGltZSo4 LzEwMDAwMDBdIgoJCgkjUmVzZXQgdGhlIGJ5dGVzXyB2YWx1ZXMgb24gdGhlIHRyYWZmaWMgc2lu awogICAgICAgICRzaW5rMCBzZXQgYnl0ZXNfIDAKCQoJI1JlLXNjaGVkdWxlIHRoZSBwcm9jZWR1 cmUKICAgICAgICAkbnMgYXQgW2V4cHIgJG5vdyskdGltZV0gInJlY29yZCIKICAgICAgICAKICAg ICAgICBzZXQgYncwIFtleHByICRidzAgLyAyMDBdCiAgICAgICAgc2V0IHRvdGFscGt0IFtleHBy ICR0b3RhbHBrdCArICRidzBdICAgICAgIAp9Cgpwcm9jIHJlY3YtcGt0cyB7fSB7CglnbG9iYWwg dG90YWxwa3Qgc2VxZXJybmIKCQoJcHV0cyAiVGhlIE51bWJlciBvZiBUb3RhbCByZWNlaXZlZCBw YWNrZXQgaXMgJHRvdGFscGt0IgoJcHV0cyAiVGhlIE51bWJlciBvZiBUb3RhbCB1bm9yZGVyZWQg cGFja2V0IGlzICRzZXFlcnJuYiIKfQoKc2V0IHBydnNlcW5iIC0xCnNldCBzZXFlcnJuYiAwCnBy b2Mgc2VxLXJlY29yZCB7c2l6ZSByYXRlIGZ0aW1lfSB7CiAgICAgICAgZ2xvYmFsIHBydnNlcW5i IHNlcWVycm5iIHNpbmswIGZzIAoJCglzZXQgbnMgW1NpbXVsYXRvciBpbnN0YW5jZV0KCQoJI1Nl dCB0aGUgdGltZSBhZnRlciB3aGljaCB0aGUgcHJvY2VkdXJlIHNob3VsZCBiZSBjYWxsZWQgYWdh aW4KICAgICAgICBzZXQgdHNpemUgW3BhcnNlLWJ3ICRzaXplXQogICAgICAgIHNldCB0cmF0ZSBb cGFyc2UtYncgJHJhdGVdCiAgICAgICAgc2V0IHRpbWUgW2V4cHIgZG91YmxlKCR0c2l6ZSkvZG91 YmxlKCR0cmF0ZSkvOC4wXQoJCgkjR2V0IHRoZSBjdXJyZW50IHRpbWUKICAgICAgICBzZXQgbm93 IFskbnMgbm93XQoJCgkjIHNlZWsgdGhlIHNlcXVlbmNlIG51bWJlciBvZiBwYWNrZXQuCglzZXQg cmV2c2VxbmIgWyRzaW5rMCBzZXQgZXhwZWN0ZWRfXQoJCglpZiB7JHBydnNlcW5iID4gJHJldnNl cW5ifSB7CgkJaW5jciBzZXFlcnJuYiAxCgl9CgkKCSMgd3JpdGUgdGhlIHNlcXVlbmNlIG51bWJl ciBvZiBwYWNrZXQgdG8gdGhlIGZpbGUKICAgICAgICBpZiB7JHBydnNlcW5iICE9ICRyZXZzZXFu Yn0gewoJCXB1dHMgJGZzICIkbm93IFskc2luazAgc2V0IGV4cGVjdGVkX10iCgkJc2V0IHBydnNl cW5iICRyZXZzZXFuYgogICAgICAgIH0KCQoJI1JlLXNjaGVkdWxlIHRoZSBwcm9jZWR1cmUKICAg ICAgICBpZiB7IFtleHByICRub3crJHRpbWVdIDwgJGZ0aW1lIH0gewoJCSRucyBhdCBbZXhwciAk bm93KyR0aW1lXSAic2VxLXJlY29yZCAkc2l6ZSAkcmF0ZSAkZnRpbWUiCiAgICAgICAgfQp9Cgoj IHJvdXRpbmcgcHJvdG9jb2wKJG5zIHJ0cHJvdG8gRFYKCiMKIyBtYWtlIG5vZGVzICYgTVBMU25v ZGVzCiMKc2V0IG5vZGUwICBbJG5zIG5vZGVdCnNldCBMU1IxICAgWyRucyBtcGxzLW5vZGVdCnNl dCBMU1IyICAgWyRucyBtcGxzLW5vZGVdCnNldCBMU1IzICAgWyRucyBtcGxzLW5vZGVdCnNldCBM U1I0ICAgWyRucyBtcGxzLW5vZGVdCnNldCBMU1I1ICAgWyRucyBtcGxzLW5vZGVdCnNldCBMU1I2 ICAgWyRucyBtcGxzLW5vZGVdCnNldCBMU1I3ICAgWyRucyBtcGxzLW5vZGVdCnNldCBMU1I4ICAg WyRucyBtcGxzLW5vZGVdCnNldCBMU1I5ICAgWyRucyBtcGxzLW5vZGVdCnNldCBub2RlMTAgWyRu cyBub2RlXQoKIwojIG1ha2UgbGlua3MKIwokbnMgZHVwbGV4LWxpbmsgJG5vZGUwICRMU1IxICAx TWIgIDEwbXMgRHJvcFRhaWwKJG5zIGR1cGxleC1saW5rICRMU1IxICAkTFNSMyAgMU1iICAxMG1z IERyb3BUYWlsCiRucyBkdXBsZXgtbGluayAkTFNSMyAgJExTUjUgIDFNYiAgMTBtcyBEcm9wVGFp bAokbnMgZHVwbGV4LWxpbmsgJExTUjUgICRMU1I3ICAxTWIgIDEwbXMgRHJvcFRhaWwKJG5zIGR1 cGxleC1saW5rICRMU1I3ICAkTFNSOSAgMU1iICAxMG1zIERyb3BUYWlsCgokbnMgZHVwbGV4LWxp bmsgJExTUjEgICRMU1IyICAxTWIgIDEwbXMgRHJvcFRhaWwKJG5zIGR1cGxleC1saW5rICRMU1Iy ICAkTFNSNCAgMU1iICAxMG1zIERyb3BUYWlsCiRucyBkdXBsZXgtbGluayAkTFNSNCAgJExTUjYg IDFNYiAgMTBtcyBEcm9wVGFpbAokbnMgZHVwbGV4LWxpbmsgJExTUjYgICRMU1I4ICAxTWIgIDEw bXMgRHJvcFRhaWwKJG5zIGR1cGxleC1saW5rICRMU1I4ICAkTFNSOSAgMU1iICAxMG1zIERyb3BU YWlsIAoKJG5zIGR1cGxleC1saW5rICRMU1IxICAkTFNSMiAgMU1iICAxMG1zIERyb3BUYWlsCiRu cyBkdXBsZXgtbGluayAkTFNSMyAgJExTUjQgIDFNYiAgMTBtcyBEcm9wVGFpbAokbnMgZHVwbGV4 LWxpbmsgJExTUjUgICRMU1I2ICAxTWIgIDEwbXMgRHJvcFRhaWwKJG5zIGR1cGxleC1saW5rICRM U1I3ICAkTFNSOCAgMU1iICAxMG1zIERyb3BUYWlsCgokbnMgZHVwbGV4LWxpbmsgJExTUjkgICRu b2RlMTAgIDFNYiAgMTBtcyBEcm9wVGFpbAoKIwojIGNvbmZpZ3VyZSBsZHAgYWdlbnRzIG9uIGFs bCBtcGxzIG5vZGVzCiMKJG5zIGNvbmZpZ3VyZS1sZHAtb24tYWxsLW1wbHMtbm9kZXMKCiMKIyBz ZXQgbGRwLW1lc3NhZ2UgY2xvbHIKIwokbnMgbGRwLXJlcXVlc3QtY29sb3IgICAgICAgYmx1ZQok bnMgbGRwLW1hcHBpbmctY29sb3IgICAgICAgcmVkCiRucyBsZHAtd2l0aGRyYXctY29sb3IgICAg ICBtYWdlbnRhCiRucyBsZHAtcmVsZWFzZS1jb2xvciAgICAgICBvcmFuZ2UKJG5zIGxkcC1ub3Rp ZmljYXRpb24tY29sb3IgIGdyZWVuCgpwcm9jIHNldC1yZXJvdXRlLWluaXQge29wdGlvbn0gewoJ Z2xvYmFsIG5zIExTUjEgTFNSOSBMU1I1CgkKCXNldCBMU1JtcGxzMSBbJExTUjEgZ2V0LW1vZHVs ZSAiTVBMUyJdCglzZXQgTFNSbXBsczUgWyRMU1I1IGdldC1tb2R1bGUgIk1QTFMiXQoJc2V0IExT Um1wbHM5IFskTFNSOSBnZXQtbW9kdWxlICJNUExTIl0KCQogICAgICAgIHN3aXRjaCAkb3B0aW9u IHsKICAgICAgICAgICAgZHJvcCAgICAgICAgICAgICAgICAgeyAjIHNldCByZXJvdXRlIGFjdGlv biB0byB0YWtlIHdoZW4gYSBsaW5rIGZhaWxzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJG5zIGVuYWJsZS1yZXJvdXRlIGRyb3AKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAkTFNSbXBsczEgZW5hYmxlLWRhdGEtZHJpdmVuCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIH0KICAgICAgICAgICAgTDNkYXRhLWRyaXZlbiAgICAgICAgeyAjIHNldCBy ZXJvdXRlIGFjdGlvbiB0byB0YWtlIHdoZW4gYSBsaW5rIGZhaWxzCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJG5zIGVuYWJsZS1yZXJvdXRlIEwzCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJExTUm1wbHM1IHNldC1wcm90ZWN0aW9uLWZsb3cgMC4xIDAuMDEg MTAgLTEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAjIHNldCBsZHAgZXZlbnRzCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJG5zIGVuYWJsZS1vbi1kZW1hbmQKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAkbnMgZW5hYmxlLW9yZGVyZWQtY29udHJvbAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICRucyBlbmFibGUtZGF0YS1kcml2ZW4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICBMM2NvbnRyb2wtZHJpdmVuICAgICB7IAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgc2V0IHJlcm91dGUgYWN0aW9uIHRv IHRha2Ugd2hlbiBhIGxpbmsgZmFpbHMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAkbnMgZW5hYmxlLXJlcm91dGUgZHJvcAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgc2V0IGxkcCBldmVudHMK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAkbnMgZW5hYmxlLWNvbnRyb2wtZHJp dmVuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgc2ltcGxl LWR5bmFtaWMgICAgICAgeyAjIHNldCByZXJvdXRlIGFjdGlvbiB0byB0YWtlIHdoZW4gYSBsaW5r IGZhaWxzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJG5zIGVuYWJsZS1yZXJv dXRlIHNpbXBsZS1keW5hbWljCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJExT Um1wbHM1IHNldC1wcm90ZWN0aW9uLWZsb3cgMC4xIDAuMDEgMTAgLTEKCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIyBzZXQgbGRwIGV2ZW50cwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICRMU1JtcGxzMSBlbmFibGUtZGF0YS1kcml2ZW4KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICBoYXNraW4gICAgICAgICAgICAgICB7 ICMgc2V0IHJlcm91dGUgYWN0aW9uIHRvIHRha2Ugd2hlbiBhIGxpbmsgZmFpbHMKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAkbnMgZW5hYmxlLXJlcm91dGUgZHJvcAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICRMU1JtcGxzNSBzZXQtcHJvdGVjdGlvbi1sc3Ag MC43IDAuMDEgMTAwMAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgIG1ha2FtICAgICAgICAgICAgICAgIHsgIyBzZXQgcmVyb3V0ZSBhY3Rpb24gdG8gdGFrZSB3 aGVuIGEgbGluayBmYWlscwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICRucyBl bmFibGUtcmVyb3V0ZSBub3RpZnktcHJlbmVnb3RpYXRlZAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICRMU1JtcGxzNSBzZXQtcHJvdGVjdGlvbi1sc3AgMC43IDAuMDEgMTAwMAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgIHNob3J0ZXN0LWR5 bmFtaWMgICAgIHsgIyBzZXQgcmVyb3V0ZSBhY3Rpb24gdG8gdGFrZSB3aGVuIGEgbGluayBmYWls cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICRucyBlbmFibGUtcmVyb3V0ZSBz aG9ydGVzdC1keW5hbWljCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJExTUm1w bHM1IHNldC1wcm90ZWN0aW9uLWxzcCAwLjcgMC4wMSAxMDAwCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJExTUm1wbHM5IGVuYWJsZS1yZXJvdXRlLWVncmVzcy1sc3IKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICBkZWZhdWx0ICAgICAgICAg ICAgICB7IHVzYWdlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhpdAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9Cgpwcm9jIHNldC1yZXJv dXRlLWV2ZW50IHtvcHRpb259IHsKCWdsb2JhbCBucyBMU1IxIExTUjMgTFNSNSBMU1I3IExTUjkK CQoJc2V0IExTUm1wbHMxIFskTFNSMSBnZXQtbW9kdWxlICJNUExTIl0KCXNldCBMU1JtcGxzMyBb JExTUjMgZ2V0LW1vZHVsZSAiTVBMUyJdCglzZXQgTFNSbXBsczUgWyRMU1I1IGdldC1tb2R1bGUg Ik1QTFMiXQoJc2V0IExTUm1wbHM3IFskTFNSNyBnZXQtbW9kdWxlICJNUExTIl0KCXNldCBMU1Jt cGxzOSBbJExTUjkgZ2V0LW1vZHVsZSAiTVBMUyJdCgkKICAgICAgICBzd2l0Y2ggJG9wdGlvbiB7 CiAgICAgICAgICAgIGhhc2tpbiAgICAgICAgICAgICAgIHsgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIyBUaGUgc2V0dXAgb2Ygd29ya2luZyBMU1AKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAkbnMgYXQgMC4wICAiJExTUm1wbHMxICBzZXR1cC1lcmxzcCAg OSAgIDNfNV83XzkgICAgIDEwMDAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIFRoZSBzZXR1cCBvZiBhbHRlcm5hdGl2ZSBM U1AKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAkbnMgYXQgMC4xICAiJExTUm1w bHMxICBzZXR1cC1lcmxzcCAgOSAgIDJfNF82XzhfOSAgICAgIDIwMDAiCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJG5zIGF0IDAuMiAgIiRMU1JtcGxzOSAgc2V0dXAtZXJsc3Ag IDkgICA3XzVfM18xX0wyMDAwICAyMDA1IgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAjIGJpbmQgYSBmbG93IHRvIExTUAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICRucyBhdCAwLjMgICIkTFNSbXBsczEgYmluZC1mbG93LWVybHNwICAgMTAgICAxMDAgICAx MDAwIgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGJpbmRpbmcgd29ya2lu ZyBMU1AgdG8gYWx0ZXJuYXRpdmUgTFNQCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJG5zIGF0IDAuMyAgIiRMU1JtcGxzMSByZXJvdXRlLWxzcC1iaW5kaW5nICAgICAgMTAwMCAg ICAyMDAwIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICRucyBhdCAwLjMgICIk TFNSbXBsczMgcmVyb3V0ZS1sc3AtYmluZGluZyAgICAgIDEwMDAgICAgMjAwNSIKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAkbnMgYXQgMC4zICAiJExTUm1wbHM1IHJlcm91dGUt bHNwLWJpbmRpbmcgICAgICAxMDAwICAgIDIwMDUiCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJG5zIGF0IDAuMyAgIiRMU1JtcGxzNyByZXJvdXRlLWxzcC1iaW5kaW5nICAgICAg MTAwMCAgICAyMDA1IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgIG1ha2FtICAgICAgICAgICAgICAgIHsgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIyBUaGUgc2V0dXAgb2Ygd29ya2luZyBMU1AKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAkbnMgYXQgMC4wICAiJExTUm1wbHMxICBzZXR1cC1lcmxzcCAgOSAgIDNfNV83 XzkgICAgIDEwMDAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAjIFRoZSBzZXR1cCBvZiBhbHRlcm5hdGl2ZSBMU1AKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAkbnMgYXQgMC4xICAiJExTUm1wbHMxICBzZXR1 cC1lcmxzcCAgOSAgIDJfNF82XzhfOSAgICAgIDIwMDAiCgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICMgYmluZCBhIGZsb3cgdG8gTFNQCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJG5zIGF0IDAuMyAgIiRMU1JtcGxzMSBiaW5kLWZsb3ctZXJsc3AgICAxMCAg IDEwMCAgIDEwMDAiCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgYmluZGlu ZyB3b3JraW5nIExTUCB0byBhbHRlcm5hdGl2ZSBMU1AKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAkbnMgYXQgMC4zICAiJExTUm1wbHMxIHJlcm91dGUtbHNwLWJpbmRpbmcgICAg ICAxMDAwICAgIDIwMDAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgc2hvcnRlc3QtZHluYW1pYyAgICAgeyAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAjIFRoZSBzZXR1cCBvZiB3b3JraW5nIExTUAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICRucyBhdCAwLjAgICIkTFNSbXBsczEgIHNldHVwLWVybHNwICA5ICAgM181 XzdfOSAgICAgMTAwMCIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGJpbmQgYSBmbG93IHRvIExTUAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICRucyBhdCAwLjMgICIkTFNSbXBsczEgYmluZC1m bG93LWVybHNwICAgMTAgICAxMDAgICAxMDAwIgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB9CiAgICAgICAgfQp9CgojIENyZWF0ZSBhIHRyYWZmaWMgc2luayBhbmQgYXR0YWNoIGl0 IHRvIHRoZSBub2RlIG5vZGU5CnNldCBzaW5rMCBbbmV3IEFnZW50L0xvc3NNb25pdG9yXQokbnMg YXR0YWNoLWFnZW50ICRub2RlMTAgJHNpbmswCiRzaW5rMCBjbGVhcgoKIyBDcmVhdGUgYSB0cmFm ZmljIHNvdXJjZQpzZXQgc3JjMCBbYXR0YWNoLWV4cG9vLXRyYWZmaWMgJG5vZGUwICRzaW5rMCAy MDAgMCAwIDUwMGtdCiRzcmMwIHNldCBmaWRfIDEwMAokbnMgY29sb3IgMTAwIG1hZ2VudGEKCnBy b2Mgbm90aWZ5LWVybHNwLXNldHVwIHtub2RlIGxzcGlkfSB7CiAgICAgICAgc2V0IG5zIFtTaW11 bGF0b3IgaW5zdGFuY2VdCglzZXQgbW9kdWxlIFskbm9kZSBnZXQtbW9kdWxlICJNUExTIl0KCQog ICAgICAgIGlmIHsgJGxzcGlkPT0xMDAxIH0gewoJCSRtb2R1bGUgc2Vjb25kYXJ5LWxzcC1iaW5k aW5nIDEwMDAgMTAwMQogICAgICAgIH0KfQoKcHJvYyBub3RpZnktZXJsc3AtZmFpbCB7bm9kZSBz dGF0dXMgbHNwaWQgdHJ9IHsKICAgICAgICBzZXQgbnMgW1NpbXVsYXRvciBpbnN0YW5jZV0KCXNl dCBtb2R1bGUgWyRub2RlIGdldC1tb2R1bGUgIk1QTFMiXQogICAgICAgIAogICAgICAgIGlmIHsg WyRub2RlIGlkXSA9PSAxICYmICRzdGF0dXM9PSJCU05vZGVFcnJvciIgfSB7CgkJJG1vZHVsZSBz ZXQtbGliLWVycm9yLWZvci1sc3BpZCAkbHNwaWQgMQogICAgICAgIH0KICAgICAgICBpZiB7IFsk bm9kZSBpZF0gPT0gMSAmJiAkc3RhdHVzPT0iTm9kZVJlcGFpciIgfSB7CgkJJG1vZHVsZSBzZXQt bGliLWVycm9yLWZvci1sc3BpZCAkbHNwaWQgLTEKICAgICAgICB9ICAgICAgICAKfQoKIyByZXJv dXRlIG1lY2hhbmlzbXMKaWYgeyRhcmdjID09IDF9IHsKCXNldC1yZXJvdXRlLWluaXQgICRhcmd2 CglzZXQtcmVyb3V0ZS1ldmVudCAkYXJndgp9IGVsc2UgewoJdXNhZ2UKCWV4aXQKfQoKJG5zIGF0 IDAuMCAicmVjb3JkIgokbnMgYXQgMC4zICJzZXEtcmVjb3JkIDIwMCA1MDBrIDIuMCIKCiRucyBh dCAwLjMgIiRzcmMwIHN0YXJ0IgoKJG5zIHJ0bW9kZWwtYXQgMC44IGRvd24gJExTUjUgJExTUjcK JG5zIHJ0bW9kZWwtYXQgMS4zIHVwICAgJExTUjUgJExTUjcKCiRucyBhdCAxLjggIiRzcmMwIHN0 b3AiCgokbnMgYXQgMi4wICJyZWN2LXBrdHMiCiRucyBhdCAyLjAgInJlY29yZCIKJG5zIGF0IDIu MCAiZmluaXNoIgoKJG5zIHJ1bgoKDQo= --=_MAILER_ATTACH_BOUNDARY_2003242165035756898537-- From nicolas@cs.virginia.edu Tue Feb 4 06:05:02 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Tue Feb 4 06:05:02 2003 Subject: [ns] End to End delay per flow evaluation: urgent!!!! In-Reply-To: References: Message-ID: <0302040859300.5932@LITHIUM> On Tue, 4 Feb 2003, De Pellegrini Francesco wrote: > the problem is I need to plot end-to-end delay for different routing > policies, and evaluate the end-to-end delay versus the packet generation > rate. This is a major headache to me, cause I cannot process the trace > file, since I need to bring Net close to congestion and the packet ID are > likely to wrap around. You could use Queue/Marker and Queue/Demarker for that. They are in the current snapshot, as well as in the patch for 2.1b9a available at http://qosbox.cs.virginia.edu/software.shtml#ns and see the script jobs-cn2002.tcl. Best, -- Nicolas From abirami sathi" hello sir, we are doing a team project in network simulation .our project title is quality of sevices gurantee for wired and wireless network using ccpf algorithm.the software used is c++ as back end and otcl as front end. we don't know about ns .the main objectives of our project is dividing the bandwidth different ranges and finding the optimalpath.the various modulescovered in our project is 1.accomplishment ofouralgorithm 1.1 calculating the feasible path 1.2. finding the optimal route 1.3. alternate route if their is any congestion 2.simulation work We want details about the following 1.How to link OTcl and C++ 2.How to implement our CCPF algorithm by project team From abirami sathi" hello sir, we are doing a team project in network simulation .our project title is quality of sevices gurantee for wired and wireless network using ccpf algorithm.the software used is c++ as back end and otcl as front end. we don't know about ns .the main objectives of our project is dividing the bandwidth different ranges and finding the optimalpath.the various modulescovered in our project is 1.accomplishment ofouralgorithm 1.1 calculating the feasible path 1.2. finding the optimal route 1.3. alternate route if their is any congestion 2.simulation work We want details about the following 1.How to link OTcl and C++ 2.How to implement our CCPF algorithm by project team From nicolas@cs.virginia.edu Tue Feb 4 06:10:07 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Tue Feb 4 06:10:07 2003 Subject: [ns] Help to use GDB In-Reply-To: <000001c2cc1e$2a71a010$afb61897@acertravelmate> References: <000001c2cc1e$2a71a010$afb61897@acertravelmate> Message-ID: <0302040903380.5932@LITHIUM> On Tue, 4 Feb 2003, Emiliano Graziosi wrote: > some time ago I posted a message decribing my problem and I received > no response at all, but now, after solving some other problems, I > absolutely have to solve it. I've downloaded the GDB 5.3 debugger, but > I can't understand how to debug my tcl script. I tried with "gdb ns > " but I get an error message, I also tried "gdb ns" but I > can't figure out how to open the tcl script. please can you tell me > how to use gdb with ns? First, please don't post in HTML. This may have explained the absence of answer to your question. Second, what you want to do is: $ gdb ns GNU gdb 2002-12-19-cvs (cygwin-special) Copyright 2002 Free Software Foundation, Inc. [blah blah blah] (gdb) set args myscript.tcl (gdb) run So: gdb from the prompt, set args from the gdb terminal. man gdb gives you all the info you need (by redirecting to the info page, and from there, to the manual.) -- Nicolas From ghiddink@agere.com Tue Feb 4 06:50:03 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Tue Feb 4 06:50:03 2003 Subject: [ns] Help to use GDB Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97D1@nl0030excuag01.agere.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CC5B.F65597D0 Content-Type: text/plain Hi, try "gdb ns" then "run " that should work. Regards, Gerrit -----Original Message----- From: Emiliano Graziosi [mailto:killa7881@libero.it] Sent: Tuesday, February 04, 2003 8:22 AM To: ns-users@ISI.EDU Subject: [ns] Help to use GDB Hi, some time ago I posted a message decribing my problem and I received no response at all, but now, after solving some other problems, I absolutely have to solve it. I've downloaded the GDB 5.3 debugger, but I can't understand how to debug my tcl script. I tried with "gdb ns " but I get an error message, I also tried "gdb ns" but I can't figure out how to open the tcl script... please can you tell me how to use gdb with ns? Thank you a lot in advance! Emiliano Graziosi P.S.: Even if I know that maybe no one will answer to my problem, well I put it here again: Hi to everyone, I'm really in trouble and I hope that the NS experts will be able to help me as soon as possible because if I can't solve this problem I can't start to carry out reliable measurements! I attach the following extract of the trace file of my network simulation: h 1 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 + 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 - 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 r 1.002106 3 1 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15 r 1.007113400 _4_ AGT --- 15 tcp 40 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [0 0] 1 0 s 1.007113400 _4_ AGT --- 16 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [0 0] 0 0 h 1.009109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 r 1.010109 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 h 1.010109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 + 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 - 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 r 1.012232 3 0 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16 h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 h 1.012232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 + 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 - 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 + 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 - 1.014937 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 r 1.015922 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17 r 1.017628 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18 r 1.025654200 _4_ AGT --- 17 tcp 1040 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [1 0] 1 0 s 1.025654200 _4_ AGT --- 19 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [1 0] 0 0 r 1.035590200 _4_ AGT --- 18 tcp 1040 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [2 0] 1 0 s 1.035590200 _4_ AGT --- 20 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [2 0] 0 0 h 1.037546 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19 r 1.038546 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19 The network topology is the following: Wired Node (ID 0) | --------------------------- LAN (ID 3) | Base Station (ID 1) Wireless Node (ID 4) Looking at the trace file you can see the tcp packet following the path: 0 -> 3, 3 -> 1 and then arrives to 4. Here the problem comes: the node 4 sends the ACK and this one follow the path: 1->3 and 3->1 (red lines) before to take the right path! Why? Is it a fault of NS or is it right?? I compared the previuos trace file with the trace file of the simulation of a wired LAN: Wired Node (ID 2)----Wired Node (ID 5) | ----------------------------------------------------LAN (ID 3) | Wired Node (ID 1)-----Wired Node (ID 4) The trace file is the following: + 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.002016 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 h 0.002016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.004046 3 2 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 - 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 r 0.006062 2 5 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0 + 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.008078 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 h 0.008078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 + 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.009078 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.010107 3 1 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 + 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 - 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 r 0.012123 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1 . . . As you can see the packet follows the path: 4->1, 1->3, 3->2 and 5->2. The ACK sent by the node 5 follows the path: 5->2, 2->3, 3->1 and 1->4. It is obvious that the strange passage of the first kind of network topology lacks (there's not the passage 2->3 and 3->2! I'm trying to understand the reason but I really can't find it out! If you could help me I would appreciate it very much, I really need an help. ------_=_NextPart_001_01C2CC5B.F65597D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi,
 
try=20 "gdb ns"
then=20 "run <tcl_script>"
 
that=20 should work.
 
Regards, Gerrit
-----Original Message-----
From: Emiliano Graziosi = [mailto:killa7881@libero.it]
Sent: Tuesday, February 04, = 2003 8:22=20 AM
To: ns-users@ISI.EDU
Subject: [ns] Help to use = GDB

Hi,

some time=20 ago I posted a message decribing my problem and I received no = response at all,=20 but now, after solving some other problems, I absolutely have to = solve it.=20 I’ve downloaded the GDB 5.3 debugger, but I can’t = understand how to debug my=20 tcl script. I tried with “gdb ns <tcl_script>” but = I get an error=20 message, I also tried “gdb ns” but I can’t figure = out how to open the tcl=20 script… please can you tell me how to use gdb with=20 ns?

 

Thank=20 you a lot in advance!

 

Emiliano=20 Graziosi

 

P.S.:=20 Even if I know that maybe no one will answer to my problem, well I = put it here=20 again:

 

Hi to=20 everyone,

I’m=20 really in trouble and I hope that the NS experts will be able to help = me as=20 soon as possible because if I can’t solve this problem I = can’t start to carry=20 out reliable measurements!

 

I attach=20 the following extract of the trace file of my network=20 simulation:

 

h 1 0 3 tcp 40 ------- = 0 0.0.1.0=20 0.1.1.0 0 15
+ 1.001 0 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 = 15
- 1.001 0=20 3 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15
r 1.002106=20 3 1 tcp 40 ------- 0 0.0.1.0 0.1.1.0 0 15
r=20 1.007113400 _4_ AGT  = --- 15 tcp 40=20 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [0 0] 1 0
s 1.007113400 _4_ AGT =20 --- 16 ack 40 [0 0 0 0] ------- [2049:0 1:0 32 0] [0 0] 0 = 0
h 1.009109=20 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16
r=20 1.010109 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 = 16
h 1.010109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 = 0 16
+=20 1.011109 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 0 16
- 1.011109 1 3 = ack 60=20 ------- 0 0.1.1.0 0.0.1.0 0 16
r = 1.012232 3 0 ack=20 60 ------- 0 0.1.1.0 0.0.1.0 0 16
h = 1.012232 0 3=20 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17
h 1.012232=20 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
+ 1.013232 0 3 tcp = 1040 -------=20 0 0.0.1.0 0.1.1.0 1 17
- 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 = 0.1.1.0 1=20 17
+ 1.013232 0 3 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
- = 1.014937 0 3=20 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
r 1.015922=20 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 1 17
r=20 1.017628 3 1 tcp 1040 ------- 0 0.0.1.0 0.1.1.0 2 18
r 1.025654200 _4_ AGT =20 --- 17 tcp 1040 [13a 5 0 800] ------- [1:0 2049:0 31 2049] [1 = 0] 1=20 0
s 1.025654200 _4_ AGT  --- 19 ack 40 [0 0 0 0] = -------=20 [2049:0 1:0 32 0] [1 0] 0 0
r = 1.035590200 _4_=20 AGT  --- 18 tcp 1040 = [13a 5 0 800]=20 ------- [1:0 2049:0 31 2049] [2 0] 1 0
s=20 1.035590200 _4_ AGT  = --- 20 ack 40=20 [0 0 0 0] ------- [2049:0 1:0 32 0] [2 0] 0 0
h 1.037546=20 1 3 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19
r=20 1.038546 3 1 ack 60 ------- 0 0.1.1.0 0.0.1.0 1 19
 =20

The=20 network topology is the following:

           =20

         =20 Wired Node (ID 0)

           &nb= sp;           =20 |

           =20 --------------------------- LAN (ID = 3)

           &nb= sp;           &nb= sp;          =20 |

           &nb= sp;           =20  Base Station = (ID=20 1)

 

           &nb= sp;           =20 Wireless Node (ID 4)

 

Looking=20 at the trace file you can see the tcp packet following the path: 0 = -> 3, 3=20 -> 1 and then arrives to 4. Here the = problem=20 comes: the node 4 sends the ACK and this one follow the path: 1->3 = and=20 3->1 (red lines) before to take the right path! Why? Is it a fault = of NS or=20 is it right??

           &nb= sp;           &nb= sp;          =20

I=20 compared the previuos trace file with the trace file of the = simulation of a=20 wired LAN:

           &nb= sp;           =20

           =20 Wired Node (ID 2)----Wired Node (ID = 5)

           &nb= sp;           =20 |

           =20 ----------------------------------------------------LAN (ID=20 3)

           &nb= sp;           &nb= sp;           &nb= sp;          =20 |

           &nb= sp;           &nb= sp;          =20 Wired Node (ID 1)-----Wired Node = (ID 4)           &nb= sp;           &nb= sp; =20

 

The=20 trace file is the following:

 

+ 0 4 1 tcp 40 = ------- 0=20 0.1.0.0 0.2.0.0 0 0
- 0 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 = 0
r
0.002016 4 1 tcp 40 ------- 0 0.1.0.0 0.2.0.0 = 0=20 0
h 0.002016 1 3 tcp 40 ------- 0 = 0.1.0.0 0.2.0.0=20 0 0
+ 0.003016 1 3 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
- = 0.003016 1 3=20 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
r = 0.004046 3=20 2 tcp 40 ------- 0 0.1.0.0 0.2.0.0 0 0
+ 0.004046 2 5 tcp 40 = ------- 0=20 0.1.0.0 0.2.0.0 0 0
- 0.004046 2 5 tcp 40 ------- 0 0.1.0.0 = 0.2.0.0 0=20 0
r 0.006062 2 5 tcp 40 ------- 0 = 0.1.0.0 0.2.0.0=20 0 0
+ 0.006062 5 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
- = 0.006062 5 2=20 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
r = 0.008078 5=20 2 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
h 0.008078=20 2 3 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
+ 0.009078 2 3 ack 40 = ------- 0=20 0.2.0.0 0.1.0.0 0 1
- 0.009078 2 3 ack 40 ------- 0 0.2.0.0 = 0.1.0.0 0=20 1
r 0.010107 3 1 ack 40 ------- 0 = 0.2.0.0 0.1.0.0=20 0 1
+ 0.010107 1 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
- = 0.010107 1 4=20 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
r = 0.012123 1=20 4 ack 40 ------- 0 0.2.0.0 0.1.0.0 0 1
           &nb= sp;           &nb= sp;           &nb= sp;          =20 .

           &nb= sp;           &nb= sp;           &nb= sp;          =20 .

           &nb= sp;           &nb= sp;           &nb= sp;          =20 .

As you=20 can see the packet follows the path: 4->1, 1->3, 3->2 and = 5->2.=20 The ACK sent by the node 5 follows the path: 5->2, 2->3, = 3->1 and=20 1->4. It is obvious that the strange passage of the first kind of = network=20 topology lacks (there’s not the passage 2->3 and=20 3->2!

 

I’m=20 trying to understand the reason but I really can’t find it out! =

 

If you=20 could help me I would appreciate it very much, I really need an help.

 

 

 

------_=_NextPart_001_01C2CC5B.F65597D0-- From SYilmaz@hc.aselsan.com.tr Tue Feb 4 07:00:14 2003 From: SYilmaz@hc.aselsan.com.tr (Semra YILMAZ) Date: Tue Feb 4 07:00:14 2003 Subject: [ns] version of ns with EDCF Message-ID: Hi all, What is the version of ns-2 that EDCF is implemented? Regards, Semra Yilmaz From andre_san@yahoo.com Tue Feb 4 07:10:05 2003 From: andre_san@yahoo.com (Andre Santana) Date: Tue Feb 4 07:10:05 2003 Subject: [ns] snoop and wireless network problem Message-ID: <20030204150553.57768.qmail@web40802.mail.yahoo.com> --0-1657079616-1044371153=:56711 Content-Type: text/plain; charset=us-ascii Dear friends, I´m a new NS user and I am triying to use snoop protocol in wired-cum-wireless networks. In order to do that I have to add snoop protocol to base station node as a link layer node. In order to do this, I've tried to run wireless2.tcl and wired-cum-wireless-sim.tcl scripts with same changes like: set $opt(ll) LL changed to become set $opt(ll) LL/LLSnoop And the problem is that nothing happened with the results (throughput). They are the same with and with out snoop protocol. I wounder if the snoop protocol works fine in the base station and If my change in the tcl script is enough to use snoop in BS. Thanks very much, André Santana - USP/LARC --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1657079616-1044371153=:56711 Content-Type: text/html; charset=us-ascii

Dear friends,

I´m a new NS user and I am triying to use snoop protocol in wired-cum-wireless networks. In order to do that I have to add snoop protocol to base station node as a link layer node. In order to do this,  I've tried to run wireless2.tcl and wired-cum-wireless-sim.tcl scripts with same changes like:

set $opt(ll) LL  changed to become set $opt(ll) LL/LLSnoop

And the problem is that nothing happened with the results (throughput). They are the same with and with out snoop protocol. I wounder if the snoop protocol works fine in the base station and If my change in the tcl script is enough to use snoop in BS.

Thanks very much,

André Santana - USP/LARC



Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1657079616-1044371153=:56711-- From fgeck@optonline.net Tue Feb 4 07:15:03 2003 From: fgeck@optonline.net (Frank) Date: Tue Feb 4 07:15:03 2003 Subject: [ns] [Fwd: Flush-trace problem?] Message-ID: <3E3FD8C9.14216084@optonline.net> No thoughts any one? No one has ever gotten this error? Even if you don't know the answer any thoughts? The only theory I have is that it is calling this finish2 during the run and this is not a first pass syntax error, so I'm loosing a pointer to something? -------- Original Message -------- Subject: Flush-trace problem? Date: Mon, 03 Feb 2003 11:53:55 -0500 From: Frank To: Network Simulator Users Ok, does any one have any idea what I did wrong here? This function / procedure is the exact same code used by other code and I call it the same way. I am writing my own gents/applications, could that cause this problem? Error: ns: finish2: invalid command name "" while executing "$self info class" (procedure "" line 3) (SplitObject unknown line 3) invoked from within "$trace flush" (procedure "_o4" line 5) (Simulator flush-trace line 5) invoked from within "$ns flush-trace" (procedure "finish2" line 3) invoked from within "finish2" Finish2.tcl proc finish2 {} { global ns $ns flush-trace #puts "running nam..." #exec nam out.nam & #exec xgraph mc.tr & exit 0 } Line that calls it: $ns at $durationOfSimulation "finish2" but seems to be failing after I call $ns run From ccarter@cs.uiuc.edu Tue Feb 4 07:35:10 2003 From: ccarter@cs.uiuc.edu (Casey Carter) Date: Tue Feb 4 07:35:10 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA References: <20030204021248.37560.qmail@web40802.mail.yahoo.com> <3E3F9C97.4050301@telecom.lth.se> Message-ID: <3E3FD48A.9020202@cs.uiuc.edu> To clarify: I know that the line is not commented -- that is the problem. To correct the problem, the line must be removed. Consider a hypothetical example: A <====> B C A and B are within range, C is far away. B sends RTS to C, sets ssrc_ to 0. C doesn't receive. Loop: B retries RTS to C, sets ssrc_ to 1. C doesn't receive. B retries RTS to C, sets ssrc_ to 2. C doesn't receive. A sends RTS to B, sets ssrc_ to 0. B receives RTS, sends CTS to A. A receives CTS, sets ssrc_ to 0, sends DATA. // Gerrit says this is a bug also: but it's not the one I refer to. B receives DATA, sends ACK to A, sets ssrc_ to 0. // THIS is the bug: B's ssrc_ is for the B-C exchange, it is unrelated to the A-B exchange. goto Loop In this way, B can continue retransmitting RTS for the exact same packet indefinitely. That's the bug I'm talking about. Ali Hamidian wrote: > Hi, > > Just wanted to conform what Alvin says: in my version of ns-2 > (ns-2.1b9a) the line > > ssrc_ = 0; > > is NOT commented - i.e. the same as Alvin says. And that's why I told > Carlos that the AODV code in ns-2.1b9a should be able to detect link > breaks pretty fast. > > Regards > Ali > > > Alvin Valera wrote: > >>Hi Casey & Carlos Miguel, >> >>I tried Carlos Miguel's test scenarios but didn't >>encounter the problem of long link layer detection >>delay. When I received this e-mail, it became apparent >>that in my version of ns-2 (ns-2.1b8 June 6, 2001 >>release), the line >> >> ssrc_ = 0; >> >>is _NOT_ commented! That's why I couldn't duplicate >>Carlos Miguel's results! >> >>I find this odd. Who commented out that line in the >>succeeding versions and for what reason? >> >>Best regards, >>Alvin >> >>--- Casey Carter wrote: >> >> >>>Analysis of the trace file (with mac trace on) >>>reveals that this problem >>>is due to a bug in the 802.11 mac implementation. >>>802.11 tries to send >>>an RTS several times (7 times in ns2) before >>>reporting failure. In the >>>ns2 mac, the retry counter is reset when the mac >>>successsfully sends or >>>_receives_ a packet. As long as node 1 in your >>>scenario keeps receiving >>>packets from node 0, before it can reach seven >>>retries, it will not >>>report failure. My trace file shows that node 1 >>>retries this particular >>>RTS about 650 times between 25 and 33.13 seconds. >>> >>>The particular culprit is in void >>>MAC802_11::recvDATA(Packet*); the >>>conditional branch that cleans up CTS packets after >>>successful reception >>>resets ssrc_, the RTS retry counter. Anybody know >>>why? Commenting out >>>the line that reads >>> >>> ssrc_ = 0; >>> >>>forces the proper behavior. >>> >>>calafate@disca.upv.es wrote: >>> >>> >>> >>>>Hi, >>>> >>>>I have sent a possible bug report to the NS mailing >>>> >>>> >>>list, but since no one was >>> >>> >>>>able to give me a reply, perhaps someone in this >>>> >>>> >>>mailing list is interested. >>> >>> >>>>Results of dozens of simulations using AODV, DSR >>>> >>>> >>>and TORA in ns2.1b9a (2.1b8 >>> >>> >>>>too) show that these protocols do not behave >>>> >>>> >>>correctly when there are 802.11 >>> >>> >>>>broken links. >>>> >>>>When looking at the overall results of simulations >>>> >>>> >>>with many nodes, the effect I >>> >>> >>>>describe is not evident. It is necessary to look at >>>> >>>> >>>a single flow to see that >>> >>> >>>>nodes fail to quickly detect broken links, making >>>> >>>> >>>the re-routing process last >>> >>> >>>>too long. This effect does not exist when using >>>> >>>> >>>other protocols like OLSR or >>> >>> >>>>Hello-driven AODV since they do not use link-layer >>>> >>>> >>>info. >>> >>> >>>>The files I attach show this problem clearly in a >>>> >>>> >>>very simple scenario >>> >>> >>>>Please help! >>>> >>>>Best regards, >>>> >>>>_________________________________________________ >>>> >>>> >>>> -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 From aleon@dcom.upv.es Tue Feb 4 07:45:04 2003 From: aleon@dcom.upv.es (Antonio Leon) Date: Tue Feb 4 07:45:04 2003 Subject: [ns] hard handover Message-ID: <000e01c2cc63$f65290f0$57202a9e@upvnet.upv.es> This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C2CC6C.5804A970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am studying handover in the protocol Mobile IP. The problem is that in = my simulations the handover is always soft handover ('make berore break) = because once the MH transmits the 'registration request' message via FA = continues receiving from HA.=20 Somebody knows how can I simulate a hard handover? Best Regards.=20 Antonio Le=F3n ------=_NextPart_000_000B_01C2CC6C.5804A970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am studying handover in the protocol Mobile IP. = The=20 problem is that in my simulations the handover is always soft handover = ('make=20 berore break) because once the MH transmits the 'registration request' = message=20 via FA continues receiving from HA.
 
Somebody knows how can I simulate a hard handover?
Best Regards.
 
Antonio = Le=F3n
------=_NextPart_000_000B_01C2CC6C.5804A970-- From ghiddink@agere.com Tue Feb 4 08:10:06 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Tue Feb 4 08:10:06 2003 Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97D2@nl0030excuag01.agere.com> Hi, You are correct, this is also a bug. The MAC simulation resets the ssrc_ in the following situations while it should leave it intact: - upon reception of DATA after having transmitted a CTS - upon transmitting a CTS after having transmitted an RTS In both situations it is incorrectly assumed that this is a "succesful frame exchange sequence" and that the ssrc_ can be reset. But doing so would (in both situations, by the way) cause the MAC to retry RTS/CTS/DATA/ACK sequences more often than the allowed maximum of 4 (default). The first case is in recvDATA, within the tx_state_==MAC_CTS branch. The second case is in recvCTS, some lines before the end of the function. Regards, Gerrit > -----Original Message----- > From: Casey Carter [mailto:ccarter@cs.uiuc.edu] > Sent: Tuesday, February 04, 2003 3:56 PM > To: Ali Hamidian > Cc: Alvin Valera; calafate@disca.upv.es; manet@ietf.org; > ns-users@ISI.EDU > Subject: [ns] Re: [manet] Error simulating with AODV, DSR and TORA > > > > To clarify: I know that the line is not commented -- that is the > problem. To correct the problem, the line must be removed. > Consider a > hypothetical example: > > A <====> B C > > A and B are within range, C is far away. > > B sends RTS to C, sets ssrc_ to 0. C doesn't receive. > Loop: > B retries RTS to C, sets ssrc_ to 1. C doesn't receive. > B retries RTS to C, sets ssrc_ to 2. C doesn't receive. > A sends RTS to B, sets ssrc_ to 0. > B receives RTS, sends CTS to A. > A receives CTS, sets ssrc_ to 0, sends DATA. > // Gerrit says this is a bug also: but it's not the one I refer to. > > B receives DATA, sends ACK to A, sets ssrc_ to 0. > // THIS is the bug: B's ssrc_ is for the B-C exchange, it is > unrelated > to the A-B exchange. > goto Loop > > In this way, B can continue retransmitting RTS for the exact > same packet > indefinitely. That's the bug I'm talking about. > > Ali Hamidian wrote: > > > Hi, > > > > Just wanted to conform what Alvin says: in my version of ns-2 > > (ns-2.1b9a) the line > > > > ssrc_ = 0; > > > > is NOT commented - i.e. the same as Alvin says. And that's > why I told > > Carlos that the AODV code in ns-2.1b9a should be able to > detect link > > breaks pretty fast. > > > > Regards > > Ali > > > > > > Alvin Valera wrote: > > > >>Hi Casey & Carlos Miguel, > >> > >>I tried Carlos Miguel's test scenarios but didn't > >>encounter the problem of long link layer detection > >>delay. When I received this e-mail, it became apparent > >>that in my version of ns-2 (ns-2.1b8 June 6, 2001 > >>release), the line > >> > >> ssrc_ = 0; > >> > >>is _NOT_ commented! That's why I couldn't duplicate > >>Carlos Miguel's results! > >> > >>I find this odd. Who commented out that line in the > >>succeeding versions and for what reason? > >> > >>Best regards, > >>Alvin > >> > >>--- Casey Carter wrote: > >> > >> > >>>Analysis of the trace file (with mac trace on) > >>>reveals that this problem > >>>is due to a bug in the 802.11 mac implementation. > >>>802.11 tries to send > >>>an RTS several times (7 times in ns2) before > >>>reporting failure. In the > >>>ns2 mac, the retry counter is reset when the mac > >>>successsfully sends or > >>>_receives_ a packet. As long as node 1 in your > >>>scenario keeps receiving > >>>packets from node 0, before it can reach seven > >>>retries, it will not > >>>report failure. My trace file shows that node 1 > >>>retries this particular > >>>RTS about 650 times between 25 and 33.13 seconds. > >>> > >>>The particular culprit is in void > >>>MAC802_11::recvDATA(Packet*); the > >>>conditional branch that cleans up CTS packets after > >>>successful reception > >>>resets ssrc_, the RTS retry counter. Anybody know > >>>why? Commenting out > >>>the line that reads > >>> > >>> ssrc_ = 0; > >>> > >>>forces the proper behavior. > >>> > >>>calafate@disca.upv.es wrote: > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>I have sent a possible bug report to the NS mailing > >>>> > >>>> > >>>list, but since no one was > >>> > >>> > >>>>able to give me a reply, perhaps someone in this > >>>> > >>>> > >>>mailing list is interested. > >>> > >>> > >>>>Results of dozens of simulations using AODV, DSR > >>>> > >>>> > >>>and TORA in ns2.1b9a (2.1b8 > >>> > >>> > >>>>too) show that these protocols do not behave > >>>> > >>>> > >>>correctly when there are 802.11 > >>> > >>> > >>>>broken links. > >>>> > >>>>When looking at the overall results of simulations > >>>> > >>>> > >>>with many nodes, the effect I > >>> > >>> > >>>>describe is not evident. It is necessary to look at > >>>> > >>>> > >>>a single flow to see that > >>> > >>> > >>>>nodes fail to quickly detect broken links, making > >>>> > >>>> > >>>the re-routing process last > >>> > >>> > >>>>too long. This effect does not exist when using > >>>> > >>>> > >>>other protocols like OLSR or > >>> > >>> > >>>>Hello-driven AODV since they do not use link-layer > >>>> > >>>> > >>>info. > >>> > >>> > >>>>The files I attach show this problem clearly in a > >>>> > >>>> > >>>very simple scenario > >>> > >>> > >>>>Please help! > >>>> > >>>>Best regards, > >>>> > >>>>_________________________________________________ > >>>> > >>>> > >>>> > > > -- > Casey Carter > Casey@Carter.net > ccarter@uiuc.edu > AIM: cartec69 > > > From aleon@dcom.upv.es Tue Feb 4 08:15:03 2003 From: aleon@dcom.upv.es (Antonio Leon) Date: Tue Feb 4 08:15:03 2003 Subject: [ns] NOAH and Windows Message-ID: <001801c2cc68$29f4f660$57202a9e@upvnet.upv.es> Somebody can tell me if I is possible install the NOAH extension in ns-2.12b9a version for windows? Thanks in advance Antonio From patilabh@msu.edu Tue Feb 4 08:50:07 2003 From: patilabh@msu.edu (Abhishek Patil) Date: Tue Feb 4 08:50:07 2003 Subject: [ns] Remember! There's a fast procedure to compile ns-2/nam-1 on Win32 Platforms In-Reply-To: <127.0.0.1+Vi1cqfse5qLWDSUIW4TMe4@all-1.inet.it> Message-ID: <20030204164944.14985.qmail@web10901.mail.yahoo.com> Hi Davide, I went thru most of the instructions given on ur page. They are good. I have linux RH8.0.. which comes with gcc3.2... ns 2.1b7a doesnt like that.. so i tried installing it into my winxp partition using cygwin... again the same problem.. the latest version of cygwin comes with gcc3.2.. I tried to configure it with gcc2.96.. didnt help. So, I am gonna try doing things the way you have mentioned ie a non-cygwin install (using visual c++). Can you upload the instructions for installing ns 2.1b7a on ur page? It'll be of great help. You might be wondering y am i still stuck with 2.1b7a... well bluehoc (ibm's xtnsion to ns) works only with that version. I have ns 2.1b9a working.. but bluehoc doesnt like it :( Thanks & Regards, Abhishek --- Davide Oscar Nitti wrote: > > Hi all, > I monthly send this e-mail at ns-users mailing list. > I developed some procedures to quickly compile ns-2/nam-1 on Win32 > Platforms (now also for WinXp). It is described at: > http://members.fortunecity.it/davosnitti/ns/howtocompile/en/index.htm > The Faq is at http://members.fortunecity.it/davosnitti/ns/faq.htm : here > there are very useful considerations for Windows users! > Other useful informations, such links to documentation for Ns-Nam, Tcl-Tk > and OTcl, are indicated at: > http://members.fortunecity.it/davosnitti/ns/index.htm > Bye, Davide Oscar Nitti > > Note: if you navigate in my website, you will see some bunners appear. > Unfortunately, this is the condition I was due to accept for having free > webspace. > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From haldar@ISI.EDU Tue Feb 4 09:25:03 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Tue Feb 4 09:25:03 2003 Subject: [ns] using different tcp stacks In-Reply-To: Message-ID: On Mon, 3 Feb 2003, Rushabh Doshi wrote: > > Hello! > > I'm looking into the effects of different TCP stacks on a certain scenario > I'm working with. > > For the default stack, I set up the scenario using > set tcp(1) [new Agent/TCP] > set tcps(1) [new Agent/TCPSink] > ... > $ftp attach-agent $tcp(1) > > Now in order to switch to another stack, say TCP/Vegas, all I have to do > is > > set tcp(1) [new Agent/TCP/Vegas] > > Is that correct? Or am I missing some furthur initializations? Yes, that should do it. --Padma > > -Rushabh > > > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From depe@dei.unipd.it Tue Feb 4 09:45:05 2003 From: depe@dei.unipd.it (De Pellegrini Francesco) Date: Tue Feb 4 09:45:05 2003 Subject: [ns] NS per flow end-to-end monitoring ........ Message-ID: hi, I need monitoring per flow ene-to-end delay: does anybody know if there exist one module which timestamps the generation of a packet ( say in a TCP source ) and timestamps its reception ( or its dropping ) on the sink side. If such module does not exist, can somebody suggest how to implemet that? Actually I am a beginner, so I don't fully understand the NS hyerarchical structure. Any hint is highly appreciated !! Francesco From nicolas@cs.virginia.edu Tue Feb 4 10:00:04 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Tue Feb 4 10:00:04 2003 Subject: [ns] NS per flow end-to-end monitoring ........ In-Reply-To: References: Message-ID: On Tue, 4 Feb 2003, De Pellegrini Francesco wrote: > I need monitoring per flow ene-to-end delay: does anybody know if there > exist one module which timestamps the generation of a packet ( say in a > TCP source ) and timestamps its reception ( or its dropping ) on the sink > side. I already answered this question when you first posted. Yes, there is, and it's in the daily snapshot, or you can download it from for ns-2.1b9a. The disciplines of interest to you are Queue/Marker, and Queue/Demarker. These are *link* disciplines. But, using them on the source and sink nodes will give you what you want/need. -- Nicolas From stefano.nicastro@worldcom.it Tue Feb 4 10:25:06 2003 From: stefano.nicastro@worldcom.it (Nicastro, Stefano) Date: Tue Feb 4 10:25:06 2003 Subject: [ns] Nam: unable to reroute the stdout Message-ID: <2FB074C218C1D211B00B0008C75DE7E603F031CA@itmil1r2.wcom.it> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CC7A.66B17EE0 Content-Type: text/plain; charset="iso-8859-1" Hi all, hope somebody can help me. I am quite new to the ns simulator, and have some problems with nam: I tried with the first example script in the ns manual, but can't run the nam animator. When the script launches the nam, a new window is opened (I am using a Windows NT station) with the following error message: unable to reroute the stdout. Then the window close down, and nam fails. I just installed the all-in-one nam package (nam-1.0a11a-win32.exe) - it seemed to work properly at the beginning, but now it always fails. Can anybody point me in the right direction? Thanks Stefano ------_=_NextPart_001_01C2CC7A.66B17EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nam: unable to reroute the stdout

Hi all,

hope somebody can help me.
I am quite new to the ns simulator, = and have some problems with nam: I tried with the first example script = in the ns manual, but can't run the nam animator. When the script = launches the nam, a new window is opened (I am using a Windows NT = station) with the following error message: unable to reroute the = stdout.

Then the window close down, and nam = fails.
I just installed the all-in-one nam = package (nam-1.0a11a-win32.exe) - it seemed to work properly at the = beginning, but now it always fails.

Can anybody point me in the right = direction?

Thanks

Stefano

------_=_NextPart_001_01C2CC7A.66B17EE0-- From aliako@grnet.gr Tue Feb 4 11:00:06 2003 From: aliako@grnet.gr (Athanassios Liakopoulos) Date: Tue Feb 4 11:00:06 2003 Subject: [ns] Problem with CBQ/WRR Message-ID: <3E400D5F.5030904@grnet.gr> --------------070307050304050207090506 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Dear All, I tried to simulate a CBQ/WRR queue but without success. I created a simple network topology of 3 nodes and enabled CBQ/WRR at the link n2 - n3. n0 \ \ CBQ/WRR n1--- n2 -----------n3 When I start executing the ns script, ns terminates with a message "abnormal termination". I used nam and I notice that ns terminates when packets form nodes n0 and n1 send simultaneously packets to node n2. Could someone help me to overcome the problem? Thanks in advance, Thanassis PS: I used a "familiar" script that I found at http://www.isi.edu/nsnam/ns/tutorial/, example V. Of course, I added some code about the CBQ/WRR. --- cut here --- #Create a simulator object set ns [new Simulator] #Define different colors for data flows $ns color 1 Blue $ns color 2 Red #Open the nam trace file set nf [open out.nam w] $ns namtrace-all $nf #Define a 'finish' procedure proc finish {} { global ns nf $ns flush-trace #Close the trace file close $nf #Execute nam on the trace file exec nam out.nam & exit 0 } # ========================================================= # Traffic Classes Configuration # ========================================================= # Set Classes # goldClass (10%) priority 1 # silverClass (20%) priority 2 # BEClass (70%) priority 9 # (priority 0 is the HIGHEST priority and 10 the LOWEST priority) # # Connect a Queue to a Classe proc connect2queue { class } { set q [new Queue/CBQ/WRR] $q set limit_ 1000 # Installs a queue object to the compound CBQ/WRR link structure $class install-queue $q } # Define topclass set topclass [new CBQClass] # topclass_ does not have a queue $topclass setparams none false 0.95 auto 9 2 0 # Define goldClass. (20%bandwidth) set goldClass [new CBQClass] connect2queue $goldClass $goldClass setparams $topclass true 0.1 auto 1 1 0 # Define silverClass. (20%bandwidth) set silverClass [new CBQClass] connect2queue $silverClass $silverClass setparams $topclass true 0.2 auto 2 1 0 # Define BEClass. (20%bandwidth) set BEClass [new CBQClass] connect2queue $BEClass $BEClass setparams $topclass flase 0.7 auto 9 1 0 # Insert classes into the link sharing structure proc insertClass2Link { link } { global topclass goldClass silverClass BEClass $link insert $topclass $link insert $goldClass $link insert $silverClass $link insert $BEClass $link bind $goldClass 1 30; #fid 1-30 $link bind $silverClass 51 60; #fid 51-60 $link bind $BEClass 90 99; #fid 90-99 # Set the CBQ algorithm [$link queue] algorithm formal } # ===================================================== # Traffic Classes Configuration (END) # ===================================================== #Create four nodes set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] #Create links between the nodes $ns duplex-link $n0 $n2 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n3 $n2 1Mb 10ms CBQ/WRR $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right #====================================================== # Insert classes into the link sharing structure set congestedLink [$ns link $n2 $n3]; # set the variable insertClass2Link $congestedLink #====================================================== #Monitor the queue for the link between node 2 and node 3 $ns duplex-link-op $n2 $n3 queuePos 0.5 #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $udp0 set class_ 1 $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0 #Create a UDP agent and attach it to node n1 set udp1 [new Agent/UDP] $udp1 set class_ 2 $ns attach-agent $n1 $udp1 # Create a CBR traffic source and attach it to udp1 set cbr1 [new Application/Traffic/CBR] $cbr1 set packetSize_ 500 $cbr1 set interval_ 0.005 $cbr1 attach-agent $udp1 #Create a Null agent (a traffic sink) and attach it to node n3 set null0 [new Agent/Null] $ns attach-agent $n3 $null0 #Connect the traffic sources with the traffic sink $ns connect $udp0 $null0 $ns connect $udp1 $null0 #Schedule events for the CBR agents $ns at 0.5 "$cbr0 start" $ns at 0.5 "$cbr1 start" $ns at 4.5 "$cbr1 stop" $ns at 4.5 "$cbr0 stop" #Call the finish procedure after 5 seconds of simulation time $ns at 5.0 "finish" #Run the simulation $ns run --- NAM output V -t * -v 1.0a5 -a 0 A -t * -n 1 -p 0 -o 0xffffffff -c 31 -a 1 A -t * -h 1 -m 2147483647 -s 0 c -t * -i 1 -n Blue c -t * -i 2 -n Red n -t * -a 0 -s 0 -S UP -v circle -c black -i black n -t * -a 1 -s 1 -S UP -v circle -c black -i black n -t * -a 2 -s 2 -S UP -v circle -c black -i black n -t * -a 3 -s 3 -S UP -v circle -c black -i black l -t * -s 0 -d 2 -S UP -r 1000000 -D 0.01 -c black -o right-down l -t * -s 1 -d 2 -S UP -r 1000000 -D 0.01 -c black -o right-up l -t * -s 2 -d 3 -S UP -r 1000000 -D 0.01 -c black -o right q -t * -s 2 -d 3 -a 0.5 q -t * -s 3 -d 2 -a 0.5 + -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null} - -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null} h -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 -1 ------- null} + -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null} - -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null} h -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 -1 ------- null} + -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 1 ------- null} - -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 1 ------- null} h -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 -1 ------- null} + -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 1 ------- null} - -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 1 ------- null} h -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 -1 ------- null} + -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 2 ------- null} - -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 2 ------- null} h -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 -1 ------- null} + -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 2 ------- null} - -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 2 ------- null} h -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 -1 ------- null} r -t 0.514 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null} + -t 0.514 -s 2 -d 3 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null} r -t 0.514 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null} + -t 0.514 -s 2 -d 3 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null} -- Athanassios Liakopoulos Greek Research & Technology Network S.A. Address: 56 Mesogion Ave., 11574, Athens Phone : +30210-7474242, +30210-7474275 Fax : +30210-7474490 mailto : aliako@grnet.gr WWW : http://www.grnet.gr/index_en.html --------------070307050304050207090506 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit
Dear All,
 I tried to simulate a CBQ/WRR queue but without success. I created a simple network 
topology of 3 nodes and enabled CBQ/WRR at the link n2 – n3. 

   n0  
     \ 
      \    CBQ/WRR
n1--- n2 -----------n3 


When I start executing the ns script, ns terminates with a message “abnormal termination”. 
I used nam and I notice that ns terminates when packets form nodes n0 and n1 send 
simultaneously packets to node n2.

Could someone help me to overcome the problem?

Thanks in advance,
Thanassis


PS: I used a “familiar” script that I found at http://www.isi.edu/nsnam/ns/tutorial/, example V. Of course, I added some code about the CBQ/WRR.


--- cut here ---

#Create a simulator object
set ns [new Simulator]

#Define different colors for data flows
$ns color 1 Blue
$ns color 2 Red

#Open the nam trace file
set nf [open out.nam w]
$ns namtrace-all $nf

#Define a 'finish' procedure
proc finish {} {
        global ns nf
        $ns flush-trace
	#Close the trace file
        close $nf
	#Execute nam on the trace file
        exec nam out.nam &
        exit 0
}

# =========================================================
# Traffic Classes Configuration
# =========================================================
# Set Classes
# 	goldClass		(10%) priority 1
# 	silverClass		(20%) priority 2
# 	BEClass		(70%) priority 9
# (priority 0 is the HIGHEST priority and 10 the LOWEST priority)
#
# Connect a Queue to a Classe
proc connect2queue { class  } { 
	set q [new Queue/CBQ/WRR]
	$q set limit_ 1000
	# Installs a queue object to the compound CBQ/WRR link structure
	$class install-queue $q
}

# Define topclass
set topclass [new CBQClass]
# topclass_ does not have a queue
$topclass setparams none false 0.95 auto 9 2 0

# Define goldClass. (20%bandwidth)
set goldClass [new CBQClass]
connect2queue $goldClass  
$goldClass setparams $topclass true 0.1 auto 1 1 0 

# Define silverClass. (20%bandwidth)
set silverClass [new CBQClass]
connect2queue $silverClass 
$silverClass setparams $topclass true 0.2 auto 2 1 0 

# Define BEClass. (20%bandwidth)
set BEClass [new CBQClass]
connect2queue $BEClass  
$BEClass setparams $topclass flase 0.7 auto 9 1 0 

# Insert classes into the link sharing structure 
proc insertClass2Link  { link } {
	global topclass goldClass silverClass BEClass 

	$link insert $topclass
	$link insert $goldClass
	$link insert $silverClass
	$link insert $BEClass

	$link bind $goldClass 1 30; #fid 1-30
	$link bind $silverClass 51 60; #fid 51-60
	$link bind $BEClass 90 99; #fid 90-99

	# Set the CBQ algorithm
	[$link queue] algorithm formal
}
# =====================================================
# Traffic Classes Configuration (END)
# =====================================================


#Create four nodes
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]

#Create links between the nodes
$ns duplex-link $n0 $n2 1Mb 10ms DropTail
$ns duplex-link $n1 $n2 1Mb 10ms DropTail
$ns duplex-link $n3 $n2 1Mb 10ms CBQ/WRR

$ns duplex-link-op $n0 $n2 orient right-down
$ns duplex-link-op $n1 $n2 orient right-up
$ns duplex-link-op $n2 $n3 orient right


#======================================================
# Insert classes into the link sharing structure 
set congestedLink [$ns link $n2 $n3];  # set the variable
insertClass2Link $congestedLink
#======================================================


#Monitor the queue for the link between node 2 and node 3
$ns duplex-link-op $n2 $n3 queuePos 0.5

#Create a UDP agent and attach it to node n0
set udp0 [new Agent/UDP]
$udp0 set class_ 1
$ns attach-agent $n0 $udp0

# Create a CBR traffic source and attach it to udp0
set cbr0 [new Application/Traffic/CBR]
$cbr0 set packetSize_ 500
$cbr0 set interval_ 0.005
$cbr0 attach-agent $udp0

#Create a UDP agent and attach it to node n1
set udp1 [new Agent/UDP]
$udp1 set class_ 2
$ns attach-agent $n1 $udp1

# Create a CBR traffic source and attach it to udp1
set cbr1 [new Application/Traffic/CBR]
$cbr1 set packetSize_ 500
$cbr1 set interval_ 0.005
$cbr1 attach-agent $udp1

#Create a Null agent (a traffic sink) and attach it to node n3
set null0 [new Agent/Null]
$ns attach-agent $n3 $null0

#Connect the traffic sources with the traffic sink
$ns connect $udp0 $null0  
$ns connect $udp1 $null0

#Schedule events for the CBR agents
$ns at 0.5 "$cbr0 start"
$ns at 0.5 "$cbr1 start"
$ns at 4.5 "$cbr1 stop"
$ns at 4.5 "$cbr0 stop"
#Call the finish procedure after 5 seconds of simulation time
$ns at 5.0 "finish"

#Run the simulation
$ns run


--- NAM output
V -t * -v 1.0a5 -a 0
A -t * -n 1 -p 0 -o 0xffffffff -c 31 -a 1
A -t * -h 1 -m 2147483647 -s 0
c -t * -i 1 -n Blue
c -t * -i 2 -n Red
n -t * -a 0 -s 0 -S UP -v circle -c black -i black
n -t * -a 1 -s 1 -S UP -v circle -c black -i black
n -t * -a 2 -s 2 -S UP -v circle -c black -i black
n -t * -a 3 -s 3 -S UP -v circle -c black -i black
l -t * -s 0 -d 2 -S UP -r 1000000 -D 0.01 -c black -o right-down
l -t * -s 1 -d 2 -S UP -r 1000000 -D 0.01 -c black -o right-up
l -t * -s 2 -d 3 -S UP -r 1000000 -D 0.01 -c black -o right
q -t * -s 2 -d 3 -a 0.5
q -t * -s 3 -d 2 -a 0.5
+ -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null}
- -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null}
h -t 0.5 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 -1 ------- null}
+ -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null}
- -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null}
h -t 0.5 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 -1 ------- null}
+ -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 1 ------- null}
- -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 1 ------- null}
h -t 0.505 -s 0 -d 2 -p cbr -e 500 -c 1 -i 2 -a 1 -x {0.0 3.0 -1 ------- null}
+ -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 1 ------- null}
- -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 1 ------- null}
h -t 0.505 -s 1 -d 2 -p cbr -e 500 -c 2 -i 3 -a 2 -x {1.0 3.0 -1 ------- null}
+ -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 2 ------- null}
- -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 2 ------- null}
h -t 0.51 -s 0 -d 2 -p cbr -e 500 -c 1 -i 4 -a 1 -x {0.0 3.0 -1 ------- null}
+ -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 2 ------- null}
- -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 2 ------- null}
h -t 0.51 -s 1 -d 2 -p cbr -e 500 -c 2 -i 5 -a 2 -x {1.0 3.0 -1 ------- null}
r -t 0.514 -s 0 -d 2 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null}
+ -t 0.514 -s 2 -d 3 -p cbr -e 500 -c 1 -i 0 -a 1 -x {0.0 3.0 0 ------- null}
r -t 0.514 -s 1 -d 2 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null}
+ -t 0.514 -s 2 -d 3 -p cbr -e 500 -c 2 -i 1 -a 2 -x {1.0 3.0 0 ------- null}



-- 

Athanassios Liakopoulos
Greek Research & Technology Network S.A.

Address: 56 Mesogion Ave., 11574, Athens
Phone  : +30210-7474242, +30210-7474275
Fax    : +30210-7474490
mailto : aliako@grnet.gr
WWW    : http://www.grnet.gr/index_en.html
--------------070307050304050207090506-- From patilabh@msu.edu Tue Feb 4 11:40:05 2003 From: patilabh@msu.edu (Abhishek Patil) Date: Tue Feb 4 11:40:05 2003 Subject: [ns] Wireless Simulation In-Reply-To: <20030201021536.74838.qmail@web40612.mail.yahoo.com> Message-ID: <20030204193945.65679.qmail@web10905.mail.yahoo.com> Hi, I still keep getting segmentation faults for certain simulations. Does anyone know how to solve this problem? I get seg fault even for the code that came default with NS - eg ~ns/tcl/ex/wireless.tcl or ~ns/tcl/ex/wireless1.tcl I followed Bhaskar's suggestion & checked for any divide-by-zero operation or any memory leak.. couldnt find any. Sometimes even simple scripts give seg fault. Regards, Abhishek --- Bhaskar Anepu wrote: > > > One reason for segmentation fault might be that you > are dividing something with zero somewhere in the > simulation. Another reason might be with the memory > locations. That is when your code tries to mess up > with them. Thanks. > > Regards, > Bhaskar > > --- Abhishek Patil wrote: > > > > > > Hi All, > > > > > > Some of the simulations were giving me a > > segmentation fault. What can be > > the reason?: > > ----------------- > > [root@localhost ex]# ns wireless.tcl > > num_nodes is set 50 > > Loading connection pattern... > > Loading scenario file... > > Load complete... > > Starting Simulation... > > Segmentation fault > > ------------------- > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From yasser.lotfy@lycos.com Tue Feb 4 12:20:02 2003 From: yasser.lotfy@lycos.com (Yasser A. Lotfy) Date: Tue Feb 4 12:20:02 2003 Subject: [ns] Warning: Traffic events are not sorted by time. Message-ID: Hi, I get this warning while running nam Warning: Traffic events are not sorted by time. Any idea on how to remove it? I generate the traffic using large scenario generator. Also, I get an error Err: no policy entry between node 46763 and -3382 In fact I have no nodes with those numbers. Any idea why the node numbers gets ruined on ns? Or even which traffic caused this error? Regards, Yasser _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus From jeffr@sfu.ca Tue Feb 4 12:30:03 2003 From: jeffr@sfu.ca (Jeff Robinson) Date: Tue Feb 4 12:30:03 2003 Subject: [ns] 802.11 Timeouts Message-ID: <20030204202756.GB10109@sfu.ca> Hey all, Does anyone know the part of the 802.11 standard that specifies values for CTSTimeout? This question was asked recently, but never answered. "CTSTimeout Interval" is mentioned in 9.2.5.7, but never defined. I'm asking because observing the ns2 802.11 MAC, I've noticed traces like the following: r -t 20.756921590 -Ni 1 -Nl MAC -Nw --- -Mt ACK s -t 20.756972585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS s -t 20.756972590 -Ni 5 -Nl MAC -Nw --- -Ms 5 -Mt RTS s -t 20.756972590 -Ni 2 -Nl MAC -Nw --- -Ms 2 -Mt RTS d -t 20.756972594 -Ni 0 -Nl MAC -Nw COL -Ms 3 -Mt RTS d -t 20.756972604 -Ni 0 -Nl MAC -Nw COL -Ms 2 -Mt RTS s -t 20.756972608 -Ni 10 -Nl MAC -Nw --- -Ms a -Mt RTS d -t 20.756972632 -Ni 0 -Nl MAC -Nw COL -Ms 5 -Mt RTS x -t 20.757324585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS x -t 20.757324590 -Ni 5 -Nl MAC -Nw --- -Ms 5 -Mt RTS x -t 20.757324590 -Ni 2 -Nl MAC -Nw --- -Ms 2 -Mt RTS x -t 20.757324608 -Ni 10 -Nl MAC -Nw --- -Ms a -Mt RTS d -t 20.757324632 -Ni 0 -Nl MAC -Nw COL -Ms a -Mt RTS s -t 20.757424585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS x -t 20.757776585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS r -t 20.757776594 -Ni 0 -Nl MAC -Nw --- -Ms 3 -Mt RTS s -t 20.757786594 -Ni 0 -Nl MAC -Nw --- -Mt CTS x -t 20.758090594 -Ni 0 -Nl MAC -Nw --- -Mt CTS r -t 20.758090604 -Ni 3 -Nl MAC -Nw --- -Mt CTS The above has all transmissions occurring at 1Mb/s, using DSSS parameters (ACK = 112 bits, PHY Header = 192 bits, SIFS = 10us, SlotTime = 20us). The code used is the Atheros EDCF code, with difs = -1 (AIFS = 1). In the above trace STAs #2, #3, #5 and #10 collide in the same timeslot. STA #3 resends (and succeeds) just 0.000099977 seconds after the end of the last colliding packet. Based on mac-802_11.h: #define CTSTimeout \ (DATA_Time(ETHER_RTS_LEN) + pifs_) I would have expected the timeout to be on the order of the transmit time for a CTS packet (about 0.000314 seconds). Perhaps someone can show me where this value is used; I have tried to understand how timers are used in mac-802_11.cc but haven't got it figured out yet. I'm also concerned because all stations not involved in the previous collision event are required to wait for EIFS (time enough for SIFS + ACK, in this case about 0.000314 seconds) after the timeout interval before starting backoff (pg. 78 of IEEE Std 802.11-1997). Simulations indicate that this behaviour is observed in the ns implementation, however it seems that colliding stations may begin to backoff after DIFS (AIFS). I'm aware that the standard says (pg. 78): All backoff slots occur ... following an EIFS period during which the medium is determined to be idle for the duration of the EIFS period following detection of a frame was not received correctly. and that colliding stations cannot use physical carrier sense to detect collisions while they are sending. But, if colliding stations can start backoff after DIFS then they have a significant advantage in gaining control of the channel (since only a small number of stations will be contending simultaneously until EIFS expires). Is it a common implementation decision to not infer (detect?) an incorrectly received packet from an ACK/CTS Timeout, and allow colliding stations to backoff after DIFS? Why then force non-colliding stations to wait for an ACK/CTS (the intention of EIFS) which may be interrupted by retransmissions from colliding stations? Thanks in advance, Jeff -- Jeff Robinson jeffr@sfu.ca From xuanc@ISI.EDU Tue Feb 4 12:50:01 2003 From: xuanc@ISI.EDU (Xuan Chen) Date: Tue Feb 4 12:50:01 2003 Subject: [ns] DiffServ question In-Reply-To: Message-ID: I am confused... Maybe, you can go through the sample scripts under ns/tcl/ex/diffserv and explain the difference between those scripts and your requirement... On Mon, 3 Feb 2003, Yasser A. Lotfy wrote: > Not exactly. I already have set up the queues. Now I'm sending traffic. my question is how to mark this traffic with specific DSCP (say 10)? > > Yasser > Carleton U > -------------------------------------------------------- > YOu mean packet code mark? You can decide it...looking at sample scripts > under ns/tcl/ex/diffserv > > -chen > > On Mon, 3 Feb 2003, Yasser A. Lotfy wrote: > > > and do you know how to mark the traffic with specific DSCP? > > Yasser > > Carleton U > > ------------------------------------------ > > Yes, you can use -1 to present any host. > > > > On Sat, 1 Feb 2003, Yasser A. Lotfy wrote: > > > > > > > > Good day, > > > I am trying to create policy entry using addPolicyEntry like this: > > > $qEdgeCore($e) addPolicyEntry [$mobileNode($m) id] \ > > > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > > > > > > the problem is that the more nodes I ad, the bigger the table > > gets, then I have to go to ~/ns/diffserv/dsPolicy.h and increase > > the MAX_POLICY_ENTRY beyond the usual 20 which berings the running > > speed of ns significantly down. > > > > > > Is there any generic policy entry to a group of nodes or to all nodes like for example: > > > > > > $qEdgeCore($e) addPolicyEntry -1 \ > > > [$coreNode($c) id] TSW3CM $iCP $cir0 $pir0 > > > To indicate that $coreNode($c) should acept any traffic (coming > > from any source) and provide QoS based on the DSCP of the traffic? > > > > > > Also can you direct me to how to mark traffic with correct DSCP at source nodes? > > > > > > Appreciate your help > > > > > > Yasser > > > carleton University > > > > > > > > > > > > > > > > > _____________________________________________________________ > Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. > http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus > -- Xuan Chen USC/ISI From haldar@ISI.EDU Tue Feb 4 14:10:02 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Tue Feb 4 14:10:02 2003 Subject: [ns] power aware routing in sensor nets In-Reply-To: <3E3EE810.70401@seas.upenn.edu> Message-ID: Checkout chapter on energy-model in ns-manual. --Padma On Mon, 3 Feb 2003, Srihari G Narasimhan wrote: > > hi all, > > can anyone give me some pointers on how and where i need to incorporate > changes in the NS -code to make a routing protocol like DSDV or aodv > power-aware ?? as in from where do i get the remaining power of nodes > and where do i plug in an algo to make the routing to keep in mind the > remaining power of different nodes. > > regards > -- srihari > --------------------------------------------------------------------- > A ship in the harbor is safe,but thats not what ships were made for. > ------------------------------------| > Srihari Narasimhan | > Graduate Student | > Electrical & Systems Engg. | > University of Pennsylvania | > ------------------------------------| > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Tue Feb 4 14:35:01 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Tue Feb 4 14:35:01 2003 Subject: [ns] How to create a base station?? In-Reply-To: <3106F19CD154D34A818258EBC4147D19570673@gabriel.ul.ie> Message-ID: Take a look at the wired-cum-wireless example in greis' tutorial http://www.isi.edu/nsnam/ns/tutorial/index.html This is an older method of creating base-station which has been deprecated. You should find the correct way of defining base station nodes in the tutorial. Also see test-suite-WLtutorial.tcl under tcl/test. I will add a comment noting the method "create-bse-station-node" to be obsolete now. --Padma On Mon, 3 Feb 2003, aiden jennings wrote: > > hello, > I am trying to simlate a mobile ip solution and am having problems trying to > set up base stations correctly. > I know this problem has been posted many times on the mailing list but I > have never seen a solution to the problem that is why I am posting it once > again. > any help would be greatly appreciated. > yours sincerely, > Aiden Jennings. > > > This is the line of my code that is creating problems: > set HA [create-base-station-node 1.0.0] > > num_nodes is set 3 > no value given for parameter "errproc" to "_o34" > (Node/MobileNode add-interface line 1) > invoked from within > "$node add-interface $chan $prop $opt(ll) $opt(mac) $opt(ifq) > $opt(ifqlen) $opt(netif) $opt(ant)" > (procedure "create-dsr-bs-node" line 5) > invoked from within > "create-$opt(rp)-bs-node $node $id" > (procedure "create-base-station-node" line 21) > invoked from within > "create-base-station-node 1.0.0" > invoked from within > "set HA [create-base-station-node 1.0.0]" > (file "wireless-mip-test.tcl" line 137) > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From nicolas@cs.virginia.edu Tue Feb 4 15:00:03 2003 From: nicolas@cs.virginia.edu (Nicolas Christin) Date: Tue Feb 4 15:00:03 2003 Subject: [ns] Online manual Message-ID: Hi, I don't know if this is by choice, or by breakage, but the automatic updates to the online versions of the ns-2 manual seem broken. The online manual hasn't been updated since April 14, 2002 for all of HTML, ps.gz, and pdf. 2.1b9 was released on April 13, which tells me it is by choice, but you probably want to change the text on the webpage. From , "The manual should be updated daily, ..." FYI, -- Nicolas From haldar@ISI.EDU Tue Feb 4 17:00:04 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Tue Feb 4 17:00:04 2003 Subject: [ns] version of ns with EDCF In-Reply-To: Message-ID: Check out msg http://mailman.isi.edu/pipermail/ns-users/2002-May/022802.html in ns-users' archive. --Padma On Tue, 4 Feb 2003, Semra YILMAZ wrote: > > Hi all, > What is the version of ns-2 that EDCF is implemented? > > Regards, > Semra Yilmaz > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From tianq@ecn.purdue.edu Wed Feb 5 05:15:10 2003 From: tianq@ecn.purdue.edu (Qingjiang Tian) Date: Wed Feb 5 05:15:10 2003 Subject: [ns] help about wireless trace file Message-ID: D 12.028332687 _1_ RTR CBK 14 cbr 240 [13a 1 1 800] [energy 499.983237] ------- [14:0 20:1 31 20] [0] 1 0 above is one line from my simulation trace file.my question is: what does CBK, or "DROP_RTR_MAC_CALLBACK" means? how can it happen? and any way to modify source code so prevent it from happening? thanks a lot for your help From shivanajaym@yahoo.com Wed Feb 5 05:15:27 2003 From: shivanajaym@yahoo.com (Shivanajay Marwaha) Date: Wed Feb 5 05:15:27 2003 Subject: [ns] how to set diff initial energy of diff nodes In-Reply-To: Message-ID: <20030205043630.63073.qmail@web12407.mail.yahoo.com> Hi all, I want to create mobile nodes in my simulation with different initial energy of each node. Is it possible. If so how to do it? Thanks, Shivanajay __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From ghiddink@agere.com Wed Feb 5 05:16:36 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Wed Feb 5 05:16:36 2003 Subject: [ns] 802.11 Timeouts Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97D3@nl0030excuag01.agere.com> Hi, if a station has sent an RTS, it can expect the medium to become busy after SIFS because the transmission of a CTS has to commence after SIFS. If the medium has not become busy after PIFS (which is SIFS plus one slot time) then the station can safely assume that no CTS is underway. That's why the transmit timeout for the RTS is set at the time to transmit the RTS plus a PIFS time. If the station has not detected the medium to be busy, at least, then it will backoff and retransmit the RTS. About the EIFS defer, a station should defer for EIFS after it has seen a frame with an FCS error. A failure to receive a CTS after having transmitted an RTS does not count as seeing a frame with an FCS error. So the station does not defer for EIFS, but only performs a DIFS defer and then proceeds to count down its backoff counter. This is at least what the standard specifies. If I remember correctly, an EIFS defer at a basic rate of 1 Mbit/s lasts for 314 uS, which is roughly equal to a backoff time of 16 slots. If the contention window is 0..15 then the station that performs a backoff has an advantage; however as the contention window increases, this advantage quickly disappears. Regards, Gerrit > -----Original Message----- > From: Jeff Robinson [mailto:jeffr@sfu.ca] > Sent: Tuesday, February 04, 2003 9:28 PM > To: ns-users@ISI.EDU > Subject: [ns] 802.11 Timeouts > > > > Hey all, > > Does anyone know the part of the 802.11 standard that > specifies values for > CTSTimeout? This question was asked recently, but never answered. > "CTSTimeout Interval" is mentioned in 9.2.5.7, but never > defined. I'm > asking because observing the ns2 802.11 MAC, I've noticed > traces like the > following: > > r -t 20.756921590 -Ni 1 -Nl MAC -Nw --- -Mt ACK > s -t 20.756972585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS > s -t 20.756972590 -Ni 5 -Nl MAC -Nw --- -Ms 5 -Mt RTS > s -t 20.756972590 -Ni 2 -Nl MAC -Nw --- -Ms 2 -Mt RTS > d -t 20.756972594 -Ni 0 -Nl MAC -Nw COL -Ms 3 -Mt RTS > d -t 20.756972604 -Ni 0 -Nl MAC -Nw COL -Ms 2 -Mt RTS > s -t 20.756972608 -Ni 10 -Nl MAC -Nw --- -Ms a -Mt RTS > d -t 20.756972632 -Ni 0 -Nl MAC -Nw COL -Ms 5 -Mt RTS > x -t 20.757324585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS > x -t 20.757324590 -Ni 5 -Nl MAC -Nw --- -Ms 5 -Mt RTS > x -t 20.757324590 -Ni 2 -Nl MAC -Nw --- -Ms 2 -Mt RTS > x -t 20.757324608 -Ni 10 -Nl MAC -Nw --- -Ms a -Mt RTS > d -t 20.757324632 -Ni 0 -Nl MAC -Nw COL -Ms a -Mt RTS > s -t 20.757424585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS > x -t 20.757776585 -Ni 3 -Nl MAC -Nw --- -Ms 3 -Mt RTS > r -t 20.757776594 -Ni 0 -Nl MAC -Nw --- -Ms 3 -Mt RTS > s -t 20.757786594 -Ni 0 -Nl MAC -Nw --- -Mt CTS > x -t 20.758090594 -Ni 0 -Nl MAC -Nw --- -Mt CTS > r -t 20.758090604 -Ni 3 -Nl MAC -Nw --- -Mt CTS > > The above has all transmissions occurring at 1Mb/s, using > DSSS parameters > (ACK = 112 bits, PHY Header = 192 bits, SIFS = 10us, SlotTime > = 20us). > The code used is the Atheros EDCF code, with difs = -1 (AIFS = 1). > > In the above trace STAs #2, #3, #5 and #10 collide in the > same timeslot. > STA #3 resends (and succeeds) just 0.000099977 seconds after > the end of > the last colliding packet. Based on mac-802_11.h: > #define CTSTimeout \ > (DATA_Time(ETHER_RTS_LEN) + pifs_) > I would have expected the timeout to be on the order of the > transmit time > for a CTS packet (about 0.000314 seconds). Perhaps someone > can show me > where this value is used; I have tried to understand how > timers are used in > mac-802_11.cc but haven't got it figured out yet. > > I'm also concerned because all stations not involved in the previous > collision event are required to wait for EIFS (time enough > for SIFS + ACK, > in this case about 0.000314 seconds) after the timeout > interval before > starting backoff (pg. 78 of IEEE Std 802.11-1997). Simulations > indicate that this behaviour is observed in the ns > implementation, however > it seems that colliding stations may begin to backoff after > DIFS (AIFS). > > I'm aware that the standard says (pg. 78): > > All backoff slots occur ... following an EIFS period > during which > the medium is determined to be idle for the duration of the EIFS > period following detection of a frame was not received > correctly. > > and that colliding stations cannot use physical carrier sense > to detect > collisions while they are sending. But, if colliding > stations can start > backoff after DIFS then they have a significant advantage in gaining > control of the channel (since only a small number of stations will be > contending simultaneously until EIFS expires). > > Is it a common implementation decision to not infer (detect?) > an incorrectly > received packet from an ACK/CTS Timeout, and allow colliding > stations to > backoff after DIFS? Why then force non-colliding stations to > wait for an > ACK/CTS (the intention of EIFS) which may be interrupted by > retransmissions from colliding stations? > > Thanks in advance, > Jeff > > -- > Jeff Robinson > jeffr@sfu.ca > From ghiddink@agere.com Wed Feb 5 05:16:52 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Wed Feb 5 05:16:52 2003 Subject: [ns] Wireless Simulation Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97D4@nl0030excuag01.agere.com> Hi, segmentation faults can (although rarely) occur if there is a hardware fault, such as a memory problem or an overheated CPU. For example if you're running an overclocked Intel processor. There are web pages around on this phenomenon. You could try to get the CPU do some other heavy task, such as "cat /dev/zero >/dev/null" and check if other programs also cause segmentation faults. If this is not the case, then it is not a hardware problem. Did you modify the ns2 code? Did the validation scripts report any errors when you installed ns2? Regards, Gerrit > -----Original Message----- > From: Abhishek Patil [mailto:patil_abhishek@yahoo.com] > Sent: Tuesday, February 04, 2003 8:40 PM > To: ns-users@ISI.EDU > Subject: Re: [ns] Wireless Simulation > > > > > Hi, > > I still keep getting segmentation faults for certain simulations. Does > anyone know how to solve this problem? I get seg fault even > for the code > that came default with NS - eg ~ns/tcl/ex/wireless.tcl or > ~ns/tcl/ex/wireless1.tcl > > I followed Bhaskar's suggestion & checked for any > divide-by-zero operation > or any memory leak.. couldnt find any. Sometimes even simple > scripts give > seg fault. > > Regards, > Abhishek > > --- Bhaskar Anepu wrote: > > > > > > One reason for segmentation fault might be that you > > are dividing something with zero somewhere in the > > simulation. Another reason might be with the memory > > locations. That is when your code tries to mess up > > with them. Thanks. > > > > Regards, > > Bhaskar > > > > --- Abhishek Patil wrote: > > > > > > > > > Hi All, > > > > > > > > > Some of the simulations were giving me a > > > segmentation fault. What can be > > > the reason?: > > > ----------------- > > > [root@localhost ex]# ns wireless.tcl > > > num_nodes is set 50 > > > Loading connection pattern... > > > Loading scenario file... > > > Load complete... > > > Starting Simulation... > > > Segmentation fault > > > ------------------- > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > From killa7881@libero.it Wed Feb 5 05:17:12 2003 From: killa7881@libero.it (Emiliano Graziosi) Date: Wed Feb 5 05:17:12 2003 Subject: [ns] Strange behaviour of wireless simulation. Message-ID: <000001c2ccf6$eb47d650$1db61897@acertravelmate> Hi there to everyone, I have the following scenario: Wired Node | --------------- LAN | BS Wireless Node And I have the following problems: 1. 1 wireless node and 1 BS: I put a CBR over UDP traffic source on the Wired Node, and a Sink on the Wireless node, well if I try to set a CBR data rate greater than 6Mb (in order to saturate the 802.11b capacity) I get the following message without an end!: Adjust position of node 1 (that is the base station!) 2. 2 BS and more than 1 Wireless Node for BS: if I try to put more than 2 nodes under the BS 1, as before I get the message: Adjust position of node 1 3. 2 BS and more than 1 Wireless node for BS: even if I put create-god [expr num_wireless_nodes * num_bs_nodes + num_bs_nodes] I get the message: MAC_802_11: accessing MAC cache_array out of range ... Why?? Well, a more general question: is it possible to put BSs nodes in a LAN or it generates all these errors?? Thank you a lot in advance Emiliano Graziosi P.S.: if you need my script in order to evaluate it... ask me for it I'll be glad to send it to you From david_o_connor202@hotmail.com Wed Feb 5 05:17:44 2003 From: david_o_connor202@hotmail.com (David O'Connor) Date: Wed Feb 5 05:17:44 2003 Subject: [ns] error model question Message-ID: Hi Is there any way to have the error model start and stop at particular times? I have a simulation scenario and only want to introduce explicit packet loss after a certain amount of time (20 simulated seconds) thanks Dave _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From reclaro@tiscali.it Wed Feb 5 05:18:03 2003 From: reclaro@tiscali.it (Andrea Rosa) Date: Wed Feb 5 05:18:03 2003 Subject: [ns] Questions about setdest Message-ID: <20030205101145.GB617@Roz> Hi all, my questions are: 1)How can i use the file generated by setdest utility in NAM, in order to display node position and movement? 2)what's meaning the "table " automatically generated at the end of a setdest file (see the example): > # Destination Unreachables: 0 > # > # Route Changes: 110 > # > # Link Changes: 43 > # > # Node | Route Changes | Link Changes > # 0 | 12 | 8 > # 1 | 13 | 1 > # 2 | 12 | 6 > # 3 | 15 | 8 > # 4 | 15 | 11 > # 5 | 9 | 5 > # 6 | 28 | 8 > # 7 | 14 | 1 > # 8 | 10 | 6 > # 9 | 12 | 5 > # 10 | 12 | 3 > # 11 | 17 | 8 > # 12 | 9 | 5 > # 13 | 24 | 5 > # 14 | 18 | 6 thanks in advance!! -- Andrea Key fingerprint = C649 4F5B 8E41 3AE8 C4F0 7285 2125 81CE 8873 F712 A visit to a strange place will bring fresh work. From muhdkhan@yahoo.com Wed Feb 5 05:45:31 2003 From: muhdkhan@yahoo.com (tahir mahjabeen) Date: Wed Feb 5 05:45:31 2003 Subject: [ns] SPIN protocol Message-ID: <20030205133013.25648.qmail@web40907.mail.yahoo.com> Hi ns-users Any one work over SPIN protocol for sensor networks? If yes, please reply waiting... thanx __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From veronicavanni@interfree.it Wed Feb 5 06:00:03 2003 From: veronicavanni@interfree.it (Veronica Vanni) Date: Wed Feb 5 06:00:03 2003 Subject: [ns] range of base station References: Message-ID: <001c01c2cd1c$f07da660$810516ac@Veronica> ----- Original Message ----- From: "Qingjiang Tian" To: "Veronica Vanni" Cc: Sent: Friday, January 31, 2003 8:20 PM Subject: Re: [ns] range of base station > > > > Hi All, > > please help me, How can I change the range of base station? > > I want that the range is 1000m, but i tried to insert the follwing command in my script: > > Phy/WirelessPhy set RXThresh_ 1.42681e-12 > > but the range is still 250m!! > > I tried to change this value in ns-default.tcl, but the range is still 250m!! > > If I don't resolve this problem, I can't to continue my work and I have a deadline very soon. > > Thank you, Veronica > yeah, i have the similar problem. in my simulation, i try to control the > transmission range of mobilenode.so if any one can figure out how to > control it, please kindly let us know. > btw, how can you know the range is still 250m? I know the range with a simple script, in which there are 1 mobile node and 1 Access Point, The MN start from AP and stop to 1000m. I run the script and after I check trace file where I observe that at 250 m all packets sent from AP to MN are dropped. Vero > thanks > > From srea@cit.ie Wed Feb 5 07:00:28 2003 From: srea@cit.ie (susan rea) Date: Wed Feb 5 07:00:28 2003 Subject: [ns] DSR source code Message-ID: <200302051500.37392.srea@cit.ie> Hi all, I'm relatively new to ns and I need to know where in the DSR source code is the cache type that is used is set - i.e . how is a simple cache, mobicache or a link cache selected. Susan -- Susan Rea Department of Electronic Engineering Cork Institute of Technology -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- From joha_nina@hotmail.com Wed Feb 5 09:00:02 2003 From: joha_nina@hotmail.com (joha fdz alvarez) Date: Wed Feb 5 09:00:02 2003 Subject: [ns] how to use 802.11b without using RTS/CTS?? Message-ID: hello, we are trying to simulate a wireless network to get the throughput with and without RTS/CTS. We are using ns 2.1b9a and Red Hat Linux distribution 7.3. We've tried to disable RTS/CTS with "MAC_MIB set RTSThreshold_ 3000 ", but it doesn't work, there is a mistake:: " invalid command name "MAC_MIB" while executing "MAC_MIB set RTSThreshold_ 3000 "" We also have tried the line "#Mac/802_11 set macmib_->RTSThreshold_ 3000", but it doesn't work neither. Don't you need to rebuild ns-2 if you change the RTSThreshold variable in your TCL script???? It would be great if someone can help us with this. Thanks Clarita and Johi _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/ From vblima@dee.isep.ipp.pt Wed Feb 5 09:40:08 2003 From: vblima@dee.isep.ipp.pt (=?iso-8859-1?Q?Ver=EDssimo?=) Date: Wed Feb 5 09:40:08 2003 Subject: [ns] Profibus protocol implemented for ns-2? Message-ID: <000001c2cd3c$95506140$1e3c88c1@bruxelas> This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2CD3C.95520EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I=92m a Master degree student in FEUP (Portugal). I=92m studding Profibus behavior and performance, and for that, I want = to simulate it in ns-2. My question is: Does anyone know where I can find (a) module(s) implementing the protocol?=20 =20 Could you kindly give some help? =20 =20 Thanks in advance =20 Best regards, =20 Ver=EDssimo Lima ------=_NextPart_000_0001_01C2CD3C.95520EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, =A0=A0=A0=A0=A0=A0 =

I’m a = Master degree student in FEUP = (Portugal).

I’m = studding Profibus behavior and performance, and for that, I want to simulate it = in ns-2.

My question = is: Does anyone know where I can find (a) module(s) implementing the protocol? =

 

Could you = kindly give some help?=A0 =

=A0

Thanks in = advance

=A0

Best = regards,

 

Ver=EDssimo Lima

------=_NextPart_000_0001_01C2CD3C.95520EF0-- From ee9902@elec.qmul.ac.uk Wed Feb 5 09:45:02 2003 From: ee9902@elec.qmul.ac.uk (Ade Adewunmi) Date: Wed Feb 5 09:45:02 2003 Subject: [ns] Dynamically varying a link's bandwidth Message-ID: <001c01c2cd3b$484fa960$ad25258a@student.elec.qmul.ac.uk> This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C2CD3B.48480840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Everyone,=20 I need to simulate a server with an exponentially varying service time. = Since service time is packet size/bandwidth, I need to vary the = bandwidth in an exponential fashion. I can't vary the packet size = (which would be an easier alternative) because in my particular = simulation the packet size must remain fixed. Does anyone know how I = would be able to dynamically vary the bandwidth. Does any one have any = ideas on any other approaches I could take to achieve an exponentially = distributed service time? I really need some help on this! Thanks, Ade ------=_NextPart_000_0019_01C2CD3B.48480840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Everyone,
I need to simulate a server with an = exponentially=20 varying service time.  Since service time is packet size/bandwidth, = I need=20 to vary the bandwidth in an exponential fashion.  I can't vary the = packet=20 size (which would be an easier alternative) because in my = particular=20 simulation the packet size must remain fixed.  Does anyone know how = I would=20 be able to dynamically vary the bandwidth.  Does any one have any = ideas on=20 any other approaches I could take to achieve an exponentially = distributed=20 service time?  I really need some help on this!
 
Thanks,
Ade
------=_NextPart_000_0019_01C2CD3B.48480840-- From ee9902@elec.qmul.ac.uk Wed Feb 5 09:45:17 2003 From: ee9902@elec.qmul.ac.uk (Ade Adewunmi) Date: Wed Feb 5 09:45:17 2003 Subject: [ns] UDP packet sizes Message-ID: <001301c2cd3a$633ec310$ad25258a@student.elec.qmul.ac.uk> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2CD3A.633414B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone! I've got a really simple topology consisting of just 2 nodes (node1 and = node2). I have a udp agent attached to node 1 and a null agent attached = to node2. Furthermore, connected to my udp agent I have an exponential = traffic source attached (using Application/Traffic/Exponential). I would = expect only packets of size 100 bytes to appear in the trace file, = however when I run the code and view the trace file I notice there are = some packets with a size of 10 bytes. Does anyone know where these = packets come from? I have included a copy of my tcl code below. Thanks, Ade set ns [new Simulator] #open files set tf [open pkt_size_tf.tr w] $ns trace-all $tf set nf [ open pkt_size.nam w] $ns namtrace-all $nf #create finish procedure proc finish {} { global ns tf nf file $ns flush-trace close $tf close $nf close $file exec nam pkt_size.nam & exit 0 } # create nodes set node1 [$ns node] set node2 [$ns node] $ns duplex-link $node1 $node2 1.5Mb 100ms DropTail set qmonitor [$ns monitor-queue $node1 $node2 [$ns get-ns-traceall]] #Create the packet that monitors the length of the queue set file [open queue_stats.tr w] proc monitor_1 {} { global file qmonitor set ns [Simulator instance] set time 0.01 set now [$ns now] set drops [$qmonitor set pdrops_] set len [$qmonitor set pkts_] puts $file "$now $drops $len" $ns at [expr $now + $time] "monitor_1" } set udp0 [new Agent/UDP] $ns attach-agent $node1 $udp0=20 set null0 [new Agent/Null] $ns attach-agent $node2 $null0 $ns connect $udp0 $null0 #Define traffic genrator set traffic [new Application/Traffic/Exponential] # $traffic set Packet_Size_ 100 $traffic set burst_time_ 0.69 $traffic set idle_time_ 1.69 $traffic set rate_ 8000 $traffic attach-agent $udp0 $udp0 set packetSize_ 100 $ns at 0.0 "$traffic start"=20 $ns at 0.0 "monitor_1" $ns at 5.0 "$traffic stop" $ns at 5.1 "finish" $ns run ------=_NextPart_000_0010_01C2CD3A.633414B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone!
I've got a really simple topology = consisting=20 of  just 2 nodes (node1 and node2). I have a udp agent attached to = node 1=20 and a null agent attached to node2.  Furthermore, connected to my = udp agent=20 I have an exponential traffic source attached (using=20 Application/Traffic/Exponential). I would expect only packets of = size 100=20 bytes to appear in the trace file, however when I run the code and view = the=20 trace file I notice there are some packets with a size of 10 = bytes.  Does=20 anyone know where these packets come from?  I have included a copy = of my=20 tcl code below.
Thanks,
Ade

set ns [new Simulator]

#open files

set tf [open pkt_size_tf.tr w]

$ns trace-all $tf

set nf [ open pkt_size.nam w]

$ns namtrace-all $nf

#create finish procedure

proc finish {} {

global ns tf nf file

$ns flush-trace

close $tf

close $nf

close $file

exec nam pkt_size.nam &

exit 0

}

 

# create nodes

set node1 [$ns node]

set node2 [$ns node]

$ns duplex-link $node1 $node2 1.5Mb 100ms DropTail

set qmonitor [$ns monitor-queue $node1 $node2 [$ns = get-ns-traceall]]

#Create the packet that monitors the length of the queue

set file [open queue_stats.tr w]

proc monitor_1 {} {

global file qmonitor

set ns [Simulator instance]

set time 0.01

set now [$ns now]

set drops [$qmonitor set pdrops_]

set len [$qmonitor set pkts_]

puts $file "$now $drops $len"

$ns at [expr $now + $time] "monitor_1"

}

set udp0 [new Agent/UDP]

$ns attach-agent $node1 $udp0

set null0 [new Agent/Null]

$ns attach-agent $node2 $null0

$ns connect $udp0 $null0

#Define traffic genrator

set traffic [new Application/Traffic/Exponential]

# $traffic set Packet_Size_ 100

$traffic set burst_time_ 0.69

$traffic set idle_time_ 1.69

$traffic set rate_ 8000

$traffic attach-agent $udp0

$udp0 set packetSize_ 100

$ns at 0.0 "$traffic start"

$ns at 0.0 "monitor_1"

$ns at 5.0 "$traffic stop"

$ns at 5.1 "finish"

$ns run

------=_NextPart_000_0010_01C2CD3A.633414B0-- From patilabh@msu.edu Wed Feb 5 09:55:02 2003 From: patilabh@msu.edu (Abhishek Patil) Date: Wed Feb 5 09:55:02 2003 Subject: [ns] [Fwd: Re: Overlay Multicast in Wireless] Message-ID: <20030205175154.1928.qmail@web10905.mail.yahoo.com> Hi Guys, Has anyone worked with Overlay Multicast in wireless environment? Does the lastest version of NS support that. If there are any sample files, please let me know where to look for it. If there are any files that I need to modify do let me know. I went thru archives. There were a few mails related to this topic. But non that answered any of the above questions. Regards, Abhishek Patil -------- Original Message -------- Subject: Re: Overlay Multicast in Wireless Date: Wed, 5 Feb 2003 15:32:45 +0000 (GMT) From: Lloyd Wood Reply-To: Lloyd Wood Organization: speaking for none To: Abhishek Patil References: <3E405775.7090508@msu.edu> I've never used wireless adhoc in ns. I doubt it's integrated with multicast (multicast: otcl routing. wireless: C++ routing. Not interoperable. Entirely separate.). I think you're doomed, basically. Ask the mailing list... On Tue, 4 Feb 2003, Abhishek Patil wrote: > Date: Tue, 04 Feb 2003 19:14:45 -0500 > From: Abhishek Patil > To: Lloyd Wood > Subject: Overlay Multicast in Wireless > > Hi Lloyd, > > I have to do some simulations on overlay multicast in a wireless > adhoc environment. I saw some of ur (interesting) replies on the ns > mailing list (dated far back in april 2001!!!). > > I am using ns-2.1b9a. Could you tell me what files need to be > modified? In your replies you mentioned that some tcl files & c++ > files would need to be modified. Do I still need to do this or does > the newer version of ns implement it? If i do need to modify files, > can you tell me which files. > > I have a lot of question related to this topic. I hope you can help > me. > > Regards, > Abhishek > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From evakt@daimi.au.dk Wed Feb 5 10:10:02 2003 From: evakt@daimi.au.dk (=?ISO-8859-1?Q?Eva_Kj=E6r_Troels?=) Date: Wed Feb 5 10:10:02 2003 Subject: [ns] Manet simulation: Signal-to-noise ratio Message-ID: <3E4152D6.5040500@daimi.au.dk> Hi! I am running manet simulations in ns2. I would like to make changes to AODV so that it will initiate a route repair before a route breaks. I intend to do this by calculating the signal-to-noise ratio. I assume that the signal-to-noise ratio should be calculated at the MAC layer (?) Does any of you have experience about this sort of thing? Hoping for a good answer :-) Eva Troels From vtamminiedi1@student.gsu.edu Wed Feb 5 10:30:04 2003 From: vtamminiedi1@student.gsu.edu (Venkata Suresh Tamminiedi) Date: Wed Feb 5 10:30:04 2003 Subject: [ns] Error in NAM Message-ID: <1044469789.7b0d83e0vtamminiedi1@student.gsu.edu> Hi, I am resending this error as I could not solve the problem by looking into your frequently asked questions about NS. When I am trying to run NS Program from the console, which makes use of NAM, it is giving me the following error: running nam... nam: no display name and no $DISPLAY environment variable To overcome from this, I have to run the programs by using XManager. Would you please let me know the way I can run the NAM programs from the console but not using XManager. Thanking You in Advance --- Suresh From Bob Blakely Wed Feb 5 11:30:03 2003 From: Bob Blakely (Bob Blakely) Date: Wed Feb 5 11:30:03 2003 Subject: [ns] Wireless Broadcast Packet... I really need help here folks Message-ID: <00a001c2cd4c$3f81b970$2e08a8c0@technocom.com> For example, I have 5 wireless nodes using a packet/agent structure derived from the ping packet/agent structure. What I need to do is send one ping and receive a response from every other node that directly hears it. So far I've been unsuccessful in all my attempts to generate a "broadcast" (one to many). Do any of you sharp fellows have the answer to my problem??? Can this even be done? Regards, Bob... --------------------------------------------------- "Beer is proof that God loves us and wants us to be happy" - Benjamin Franklin From mesarina@CS.UCLA.EDU Wed Feb 5 12:30:04 2003 From: mesarina@CS.UCLA.EDU (Malena Mesarina) Date: Wed Feb 5 12:30:04 2003 Subject: [ns] agent not recognized In-Reply-To: Message-ID: Yes, I do Lina, the problem was that I forgot to install the tcl8 and tck8 packages after I downloaded them, so no shared libraries where install. My computer was using the default tcl that it came with, which is not the ns2 tcl package. So of course when my tcl file was parsed ns2 didn't recognize my new agent, because the default tcl didn't recogonize that "new Agent/..." instruction. I installed the ns2 software package by package, I didn't use ns-allinone. If you ahve problems with ns-allione, than I don't know if what I am going to describe will help you. So the thing to do is to install tcl and tk8 properly: run the following command in the tcl/unix and tk8/unix directories: ./configure make make install (YOU have to BE ROOT first ) hope this helps -Malena < On Wed, 5 Feb 2003, Lina Brito wrote: > Hello! > > I have exactly the same problem as you. Do you already now the solution for > this problem? > > Thanks in advance > > Best Regards > > Lina Brito > (Portugal) > > > > -----Mensagem original----- > De: ns-users-admin@ISI.EDU [mailto:ns-users-admin@ISI.EDU]Em nome de > Malena Mesarina > Enviada: quinta-feira, 9 de Janeiro de 2003 17:34 > Para: ns-users@ISI.EDU > Assunto: [ns] agent not recognized > > > > Hi, > > I have the same problem mentioned by Vasaky in his email of Jan 8 2003 and > I have looked at the replies he got and follow the suggestions given. > However I still have the following problem. > > I just want to run the example on how to do OTcl Linkage described by Joe > Chung in http://nile.wpi.edu/NS/. I downloaded the C++ and the *.tcl file > (ex-linkage.cc and ex-linkage.tcl) and store them in the ns2/ directory > and did the following changes to ns2: > > 1. Added the ex-linkage.o to the Makefile > 2. Registered the new Agent " MyAgentOtcl" in the tcl/lib/ns-packet.tcl > 3. Run "make depend" and "make" > > And after all this I still get the following errors when running: > ns ex-linkage.tcl > > while executing > "Agent/MyAgentOtcl create _o3 " > invoked from within > "catch "$className create $o $args" msg" > (procedure "new" line 3) > invoked from within > "new Agent/MyAgentOtcl" > invoked from within > "set myagent [new Agent/MyAgentOtcl]" > (file "ex-linkage.tcl" line 5) > > It looks the Agent is still not recognized. > > If anyone could please help me with this problem I would appreciate it. > > I am just trying to get this example work, so I presume the problem should > be simple to solve. > > thank you > > -Malena > > > > > < > From tianq@ecn.purdue.edu Wed Feb 5 12:35:09 2003 From: tianq@ecn.purdue.edu (Qingjiang Tian) Date: Wed Feb 5 12:35:09 2003 Subject: [ns] help about wireless trace file In-Reply-To: Message-ID: D 12.028332687 _1_ RTR CBK 14 cbr 240 [13a 1 1 800] [energy 499.983237] ------- [14:0 20:1 31 20] [0] 1 0 above is one line from my simulation trace file.my question is: what does CBK, or "DROP_RTR_MAC_CALLBACK" means? how can it happen? and any way to modify source code so prevent it from happening? btw, i am using DSDV as my routing protocol. thanks a lot for your help From ellich8459@yahoo.com Wed Feb 5 13:25:01 2003 From: ellich8459@yahoo.com (elliot chen) Date: Wed Feb 5 13:25:01 2003 Subject: [ns] How create default trace file in Http model Message-ID: <20030205212213.87225.qmail@web14501.mail.yahoo.com> Hi I'm trying to simulate web cache protocol by modifying web cache model provided by ns. I found Http.cc creates its own trace file, http.log but I want to create trace file which records every event by $ns trace-all [open out.tr w] But all I got is the empty file. Is this default trace functoverriddeniden disable or that's because in Http protocol actual packet is not created by any any agent? Thanks for your help in advance.Elise Ellise huang __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From hemant@cs.cmu.edu Wed Feb 5 14:05:07 2003 From: hemant@cs.cmu.edu (hemant) Date: Wed Feb 5 14:05:07 2003 Subject: [ns] trouble using tracegraph Message-ID: Hi, i get the following error when i run tracegraph on a sample .tr file. Warning: COLON arguements must be real scalars ERROR: cannot read the file Trouble reading number from file (row 119, field 8) ==> e 14 -1 -2 4\n Can someone tell me what the problem could be ? The "file" mentioned in the above error message is a "temp" file created by tracegraph itself. thanks From ravik@bgnet.bgsu.edu Wed Feb 5 14:40:01 2003 From: ravik@bgnet.bgsu.edu (Ravi) Date: Wed Feb 5 14:40:01 2003 Subject: [ns] Wireless protocol. Message-ID: <1044484671.smmsdV1.1.0@smtp.bgsu.edu> Hi everyone, I have question regarding the MAC protocol of NS. The manual says NS follows 802.11 MAC ptotocol. My question is can this be used to simulate a network which follows 802.11b protocol. If any changes are required, what are they? Thank you all in advance. Regards, Ravi From aditya@ittc.ku.edu Wed Feb 5 15:25:04 2003 From: aditya@ittc.ku.edu (Aditya Mandapaka) Date: Wed Feb 5 15:25:04 2003 Subject: [ns] problems with implementing manet routing protocol (target_ is NULL) In-Reply-To: <3E3F6C9B.8060103@daimi.au.dk> Message-ID: Eva, Thanks for the email. Now I have a doubt. If you had to add the capability of handling broadcast packets to the link layer yourself, do you mean to say that there is no broadcast mechanism implemented in stock ns-2? How are the IP_BROADCAST packets handled then, in stock ns-2 and not in your implementation? -Addie -- Aditya "Addie" Mandapaka The WiSP project ITTC, KU -------------------------------------------------------------------------- "I am glad the world's constantly changing, that way I can't be wrong all the time" =========================================================================== From haldar@ISI.EDU Wed Feb 5 16:55:01 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Wed Feb 5 16:55:01 2003 Subject: [ns] how to use 802.11b without using RTS/CTS?? In-Reply-To: Message-ID: I don't think the MAC_MIB values are bound variables and so can be set from otcl. You need to change it in the 802_11.h file where it is defined as #define MAC_RTSThreshold 0 --Padma On Wed, 5 Feb 2003, joha fdz alvarez wrote: > > > hello, > we are trying to simulate a wireless network to get the throughput with > and > without RTS/CTS. We are using ns 2.1b9a and Red Hat Linux distribution > 7.3. > We've tried to disable RTS/CTS with "MAC_MIB set RTSThreshold_ 3000 ", > but it doesn't work, there is a mistake:: " invalid command > name "MAC_MIB" > while executing > "MAC_MIB set RTSThreshold_ 3000 "" > We also have tried the line "#Mac/802_11 set macmib_->RTSThreshold_ 3000", > but it doesn't work neither. > Don't you need to rebuild ns-2 if you change the RTSThreshold variable in > your TCL script???? > It would be great if someone can help us with this. > Thanks > Clarita and Johi > > > > > > _________________________________________________________________ > MSN. Más Útil Cada Día http://www.msn.es/intmap/ > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Wed Feb 5 16:55:16 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Wed Feb 5 16:55:16 2003 Subject: [ns] DSR source code In-Reply-To: <200302051500.37392.srea@cit.ie> Message-ID: The DSR source code resides under ~ns/dsr. --Padma On Wed, 5 Feb 2003, susan rea wrote: > > Hi all, > > I'm relatively new to ns and I need to know where in the DSR source code is > the cache type that is used is set - i.e . how is a simple cache, mobicache > or a link cache selected. > > Susan > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Wed Feb 5 17:10:03 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Wed Feb 5 17:10:03 2003 Subject: [ns] how to set diff initial energy of diff nodes In-Reply-To: <20030205043630.63073.qmail@web12407.mail.yahoo.com> Message-ID: Don't think that is possible with the current energy model. But you could change that to have each node keep track of its energy parameters (something similar to its location parameter). --Padma On Tue, 4 Feb 2003, Shivanajay Marwaha wrote: > > Hi all, > I want to create mobile nodes in my simulation with > different initial energy of each node. > Is it possible. If so how to do it? > > Thanks, > Shivanajay > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Wed Feb 5 17:10:20 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Wed Feb 5 17:10:20 2003 Subject: [ns] Online manual In-Reply-To: Message-ID: Thanks for pointing this out. We'd be working on fixing it. --Padma On Tue, 4 Feb 2003, Nicolas Christin wrote: > > Hi, > > I don't know if this is by choice, or by breakage, but the automatic > updates to the online versions of the ns-2 manual seem broken. The > online manual hasn't been updated since April 14, 2002 for all of HTML, > ps.gz, and pdf. 2.1b9 was released on April 13, which tells me it is by > choice, but you probably want to change the text on the webpage. From > , "The manual should > be updated daily, ..." > > FYI, > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From haldar@ISI.EDU Wed Feb 5 17:20:02 2003 From: haldar@ISI.EDU (Padmaparna Haldar) Date: Wed Feb 5 17:20:02 2003 Subject: [ns] help about wireless trace file In-Reply-To: Message-ID: This is a packet being dropped at the routing agent typically due to a link failure. See the context where the rtg agent drops the packet to find the drop reason and hence how to prevent it. --Padma On Tue, 4 Feb 2003, Qingjiang Tian wrote: > > D 12.028332687 _1_ RTR CBK 14 cbr 240 [13a 1 1 800] [energy 499.983237] > ------- [14:0 20:1 31 20] [0] 1 0 > > above is one line from my simulation trace file.my question is: > what does CBK, or "DROP_RTR_MAC_CALLBACK" means? how can it happen? and > any way to modify source code so prevent it from happening? > > thanks a lot for your help > -- ------------------------------------------------ Be true to your work, your word, and your friend. --Thoreau Padmaparna Haldar From tianq@ecn.purdue.edu Wed Feb 5 18:15:11 2003 From: tianq@ecn.purdue.edu (Qingjiang Tian) Date: Wed Feb 5 18:15:11 2003 Subject: [ns] help about wireless trace file In-Reply-To: Message-ID: Dear Padma, well,currently , i am using DSDV as my routing protocol. if CBK means a link failure,but from my simulation,the node can transmitted its packet to the same destnation.does that mean the route is not available only at beginning,but after a while, the information is available for the information. do you have any idea how to modify DSDV.cc code to prevent such dropping? any other's responses are also appreciated. thx a lot, > > > This is a packet being dropped at the routing agent typically due to a > link failure. See the context where the rtg agent drops the packet to find > the drop reason and hence how to prevent it. > > --Padma > On Tue, 4 Feb 2003, Qingjiang Tian wrote: > > > > > > D 12.028332687 _1_ RTR CBK 14 cbr 240 [13a 1 1 800] [energy 499.983237] > > ------- [14:0 20:1 31 20] [0] 1 0 > > > > above is one line from my simulation trace file.my question is: > > what does CBK, or "DROP_RTR_MAC_CALLBACK" means? how can it happen? and > > any way to modify source code so prevent it from happening? > > > > thanks a lot for your help > > > > -- > ------------------------------------------------ > Be true to your work, your word, and your friend. > --Thoreau > > Padmaparna Haldar > > From wowman_@hanmail.net Wed Feb 5 19:15:13 2003 From: wowman_@hanmail.net (wow_wow) Date: Wed Feb 5 19:15:13 2003 Subject: [ns] [About overlap area in 802.11b] Message-ID: <20030206121418.HM.n00000000042vBR@www50.hanmail.net> Dear users,

I have some question and the answer will be very precious to me.

I am currently simulating roaming using Mobile IP in IEEE802.11.
(in my simulation, I set route update delay to 0, DSDV update period is set 1)

But, I have some confusion during simulation.

When mobile node locate in overlap area during mobile IP handoff,

it receive packets from two base station(old BS and new BS).

I know that 802.11 standard for wirelesss Area networks is unable to provide

connectivity to multiple wireless segments when the mobile node resides in their overlap.

if i know correctly about that,

Is it the bug in 802.11 implementation of NS-2?

Please let me know about this
.
Thanks in advance



"¿ì¸® ÀÎÅͳÝ, Daum" http://www.daum.net  ¡ºÆò»ý¾²´Â ¹«·á ÇѸÞÀϳݡ»
ÇÁ¸®¹Ì¾ö ¸ÞÀÏ ½áº¸¼Ì¾î¿ä?
6°¡Áö ½ºÅ²+¿ë·®È®Àå+¥á ³ª¸¸ÀÇ ¸ÂÃã ¸ÞÀÏ!
Daum¾îÇпø
ü°èÀûÀÎ ¿µ¾îÀü¹®ÄÚ½º
From yuanyg@cs.dartmouth.edu Wed Feb 5 19:45:06 2003 From: yuanyg@cs.dartmouth.edu (Yougu Yuan) Date: Wed Feb 5 19:45:06 2003 Subject: [ns] Timer question in wireless simulation Message-ID: <200302052222.08466.yuanyg@cs.dartmouth.edu> Hi, all, When I'm analyzing the result of wireless simulation (using 802.11), I noticed some annoying (for me anyway) time scale problem. For example, sending an RTS with bandwidth 1Mbps should take 44 * 8 / 1e6 = 352 microsecond, or 0.000352 second, I use Scheduler::instance().clock() to print out the simulation time right before and after the RTS sending, the difference is 0.00004 second, but the txtime() of the packet is correctly computed and is 0.000352 indeed. Is there some kind of rounding up that I don't know? Or is it caused by that the simulator only supports the 0.00001 second time scale by default? If it's the latter case, is there an option to change it? I'm asking this because I'm trying to do comparison with the wireless simulator that we are developing. Thanks for comments and suggestions. -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College From hsreenivas@mail.unomaha.edu Thu Feb 6 05:15:17 2003 From: hsreenivas@mail.unomaha.edu (hsreenivas@mail.unomaha.edu) Date: Thu Feb 6 05:15:17 2003 Subject: [ns] question on ns-2.1b7a allinone package Message-ID: Hello, I'm trying to install bluehoc that requires ns version 2.1b7a and I'm having problems installing the ns-allinone-2.1b7a version that I downloaded from http://www.isi.edu/nsnam/dist/ The error messages I get are enclosed below. I would appreciate any help in this regard -- thank you! Hiranmayi. ============================================================ * Build XGraph-12.1 ============================================================ loading cache ./config.cache checking for a BSD compatible install... ./install-sh -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... ./configure: make: not found no checking for working aclocal... missing checking for working autoconf... missing checking for working automake... missing checking for working autoheader... missing checking for working makeinfo... missing checking if malloc debugging is wanted... no checking for gcc... no checking for cc... no configure: error: no acceptable cc found in $PATH /space/ns2/ns-allinone-2.1b7a/install: make: not found Can not create xgraph; But xgraph is an optional package, continuing... ============================================================ * Build CWeb ============================================================ Making cweb /space/ns2/ns-allinone-2.1b7a/install: make: not found cweb failed to make, but it's optional chmod: WARNING: can't access cweave chmod: WARNING: can't access ctangle ln: cannot create cweave: File exists ln: cannot create ctangle: File exists ============================================================ * Build Stanford GraphBase ============================================================ Making sgb /space/ns2/ns-allinone-2.1b7a/install: make: not found Unable to create sgb library, but it's optional, so continuing... ============================================================ * Build GT-ITM ============================================================ sgb lib not found. gt-itm & sgb2ns could not be installed. Continuing.. ============================================================ * Build zlib ============================================================ Checking for gcc... Building static library libz.a version 1.1.3 with cc. Checking for unistd.h... No. Checking for errno.h... No. Checking for mmap support... No. /space/ns2/ns-allinone-2.1b7a/install: make: not found Zlib make failed, but it's optional Continue ... ============================================================ * Build tcl8.3.2 ============================================================ loading cache ./config.cache checking for ranlib... : checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. tcl8.3.2 configuration failed! Exiting ... Tcl is not part of the ns project. Please see www.Scriptics.com to see if they have a fix for your platform. From lsi@world.std.com Thu Feb 6 05:15:35 2003 From: lsi@world.std.com (David Beberman) Date: Thu Feb 6 05:15:35 2003 Subject: [ns] 802.11a datarate vs. SNR values for new phy model Message-ID: <001301c2cda0$db346260$0a01a8c0@pcbeberman> Hi, I'm working on a slightly more detailed channel, phy, and mac simulation for 802.11a. Should be a combination of the 802.11E mac source code I've downloaded from pointers from this list, combined with a co-channel, adjacent channel, and nonadjacent channel interference model. I can use the attenuation mask and the rejection numbers from the IEEE spec. Right now, I'm looking for a table of approximate SNR required for each datarate (6,12,18, etc.). I can extrapolate from the IEEE spec., white papers from various company websites, and dsp textbooks. Just thought I'd see if anybody had a list of known working values. Thanks, David Beberman lsi@world.std.com From aditya@ittc.ku.edu Thu Feb 6 05:15:48 2003 From: aditya@ittc.ku.edu (Aditya Mandapaka) Date: Thu Feb 6 05:15:48 2003 Subject: [ns] doubts regarding broadcast Message-ID: Hello, Can someone please tell me where the generic code that handles the ip packets with destination set to IP_BROADCAST is located ? I expected it to be in the link layer implementations somewhere like /mac/ll.cc but there is no mention. I guess, put in a different way, this is what I need to know - How are broadcast IP packets handled in stock ns2 ? how are they actually broadcast?? Any help would be very very useful. I am on a serious time crunch here. Thank you, Addie -- Aditya "Addie" Mandapaka The WiSP project ITTC, KU -------------------------------------------------------------------------- "I am glad the world's constantly changing, that way I can't be wrong all the time" =========================================================================== From aymbpc@umkc.edu Thu Feb 6 05:16:11 2003 From: aymbpc@umkc.edu (Mansata, Ajay Y. (UMKC-Student)) Date: Thu Feb 6 05:16:11 2003 Subject: [ns] calculating queue sizes Message-ID: <33A4B005B4601144B4B6A9E2D0A21BEA4521DC@KC-MAIL3.kc.umkc.edu> Hi All I am studying RIO-C. i would like to calculate the average queue size.Can someone please let me know how can i calculate the average queue size at a gateway. Would queue monitor help or is there a way to find out the queue limit at a bottleneck link Ajay From samson.lee@uts.edu.au Thu Feb 6 05:16:25 2003 From: samson.lee@uts.edu.au (Samson Lee) Date: Thu Feb 6 05:16:25 2003 Subject: [ns] configQ command Message-ID: <000c01c2cdb0$1edf15f0$0200a8c0@peanut> This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C2CE0C.5241AB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The manual states, "... the configQ commands set the RED parameters for = each virtual queue. Note that as the precedence value increases, the RED parameters become harsher." Not sure what parameters are .. don't think it says anything about it in that chapter .. maybe i need to look harder .. which page or section? or = can somebody just explain the parameters again? $qEC configQ 0 0 20 40 0.02 $qEC configQ 0 1 10 20 0.10 $qEC configQ Thanks .. ---------------------------- check ns manual chapter 'Differentiated Services Module' (in the end of chapter) On Mon, 9 Dec 2002, A. Pauline Jacqueline wrote: > > Hi, > > Can some one explain me about the configQ command which is used to = specify > the RED parameters for the queues. > > Thanks, > Pauline > > > ----- Original Message ----- > From: > To: > Sent: Monday, December 09, 2002 4:05 AM > Subject: Ns-users digest, Vol 1 #430 - 10 msgs > > > > Send Ns-users mailing list submissions to > > ns-users@isi.edu > > > > 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 > > ns-users-request@isi.edu > > > > You can reach the person managing the list at > > ns-users-admin@isi.edu > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Ns-users digest..." > > > > > > Today's Topics: > > > > 1. What is *rtt_seq_* ? (Liangping Ma) > > 2. Re: [Q] How to get 802.11 throughput. (Michael Mercurio) > > 3. About the energy model! (horner@peoplemail.com.cn) > > 4. GPRS crash (Was: Re: your mail) (Nicolas Christin) > > 5. help about ns-2 (horner@peoplemail.com.cn) > > 6. AODV Extension - New Packet type (Rudhrakumar Venkatesan) > > 7. queue length in wireless nodes (Kaushik Mitra) > > 8. some questions (Semra YILMAZ) > > 9. How can I know the connection number of queue/buffer? (wang = bin) > > 10. RE: demonstrating Mobile IP (aiden jennings) > > > > --__--__-- > > > > Message: 1 > > From: "Liangping Ma" > > To: ns-users@ISI.EDU > > Date: Sat, 07 Dec 2002 17:42:49 -0500 > > Subject: [ns] What is *rtt_seq_* ? > > > > Hi, > > > > Can anyone tell me what exactly the rtt_seq_ is ? And what it is = for? > > > > The following is from tcp.h > > > > int rtt_active_; /* 1 if a rtt sample is pending */ > > int rtt_seq_; /* seq # of timed seg if rtt_active_ is 1 */ > > double rtt_ts_; /* time at which rtt_seq_ was sent */ > > > > I am confused by these comments. > > > > And I tried tracing these variables, which gave the following > > (where rtt_ is the round-trip time, and the timestamps option is = used) > > time rtt_ rtt_seq_ rtt_active_ > > 1.06096 0 0 3 0 0.061 0 1 > > 1.13344 0 0 3 0 0.072 1 1 > > 1.14144 0 0 3 0 0.080 3 1 > > 1.20592 0 0 3 0 0.072 3 1 > > 1.21392 0 0 3 0 0.080 7 1 > > 1.22992 0 0 3 0 0.088 7 1 > > 1.27840 0 0 3 0 0.072 7 1 > > 1.28640 0 0 3 0 0.080 15 1 > > 1.30240 0 0 3 0 0.088 15 1 > > 1.31840 0 0 3 0 0.096 15 1 > > 1.33440 0 0 3 0 0.104 15 1 > > 1.35088 0 0 3 0 0.072 15 1 > > ... > > There are no retransmissions or duplicate acks during this period of > > simulation. > > > > Any help is appreciated! > > > > Liangping > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=3Dfeatures/featuredemail > > > > > > --__--__-- > > > > Message: 2 > > Date: Sat, 7 Dec 2002 21:37:13 -0500 (EST) > > From: Michael Mercurio > > To: Park Seok Jong > > cc: ns-users@ISI.EDU > > Subject: Re: [ns] [Q] How to get 802.11 throughput. > > > > I guess a question for you is you're looking for average throughput = at > > which layer? If I wanted to compute the average throughput of = 802.11, I > > would be counting bytes of the layer above (IP perhaps), and forget about > > trying to count all the 802.11 MAC overhead. > > > > For example, if I sent 1000 bytes of IP data from node A to node B = in X > > seconds, that throughput calculation includes all the MAC overhead. = If I > > wanted IP overhead as well, I would count the packets at the = application > > layer. To me, it all depends on your point of reference. > > > > m > > -- > > Michael Mercurio > > lafcadio@bu.edu > > > > On Sat, 7 Dec 2002, Park Seok Jong wrote: > > > > > > > > hi, > > > > > > I simulate 802.11 adhoc network, want to get overall throughput. > > > average throughput / one link(say, from node 0 to node 1) can be > obtainded in following way. > > > some one (I forget his name. -.-; ) has posted this in this = mailing > list, and I fix it a little. > > > > > > protocol overhead. > > > DIFS + 3*SIFS + contention window size*Slot time > > > + RTS packet Transmission time(20 bytes) > > > + CTS packet Transmission time(14 bytes) > > > + ACK Transmission time(14 bytes) > > > (transmission time include 192 bit PLCP header in basic rate, = 1Mbps) > > > > > > upper layer protocol overhead(in case of using CBR traffic) > > > UDP + IP + 802.11MAC =3D 8 + 20 + 34 bytes > > > and lower layer PLCP head =3D 192bit.(24 bytes) > > > so, layer overhead / one generated CBR pkt is (8+20+34) + 24 = bytes. > > > > > > throughput =3D data rate * (pkt size in byte * 8 / data rate ) / > > > { (pkt size in byte * 8 / data rate) + layer overhead * 8 / data = rate + > 192us + protocol overhead} > > > > > > If above calculation is right, I can obtain avg throughput / one > directional link. > > > this one is almost same with all nodes, because only variable is > contention windowsize > > > and this one get to be trivial compared to pkt size when = multiplied by > slot time, 20us. > > > > > > Now, what I am curious is how I can obtain overall system = throughput. > > > to solve this problem, I count pkt from upper layer in recv = function > > > of 802.11.cc, and count ack pkts in one node. after simulation, I = got, > > > say 1000 pkt of transmission in this layer. and got , say 800 ack = pkts > > > in one node. so, I conclude effective throughtput is (throughput = by > > > above formula * 800 / 1000.) > > > > > > but this conclusion make me confused. after I do this simulation, = I > > > got effective throughput about 1.5 Mbps when data rate 2Mbps with = CBR > > > pkt size 2000 bytes. I read some e-mail discussing throughput of > > > 802.11 system, but they said much lower throughput. > > > > > > can anyone tell me how I can calculate throughput of 802.11 = system? > > > > > > Best Wishes. > > > > > > Park, Seok Jong wrote from south korea. > > > > > > > > > > > > --__--__-- > > > > Message: 3 > > Date: Sun, 8 Dec 2002 12:55:36 +0800 (CST) > > From: horner@peoplemail.com.cn > > To: ns-users@ISI.EDU > > Cc: > > Subject: [ns] About the energy model! > > > > hi! > > I am sorry to trouble you. Now I am newer of ns-2 and.Now I am = seeing the > chapter of EnergyModel and Radio propagation models of ns-2!I am = confused > that the communication range is nnot ralation with the transmmision > energy!Just change the recv threshild!! it is meaning to change the > transmission energymodel and the recv threshold is the same! maybe it = is > nosense question.? > > please echo to the e-mail:horner@peoplemail.com.cn > > ------------------------------------------------------------------ > > = =C8=CB=C3=F1=CD=F8=A1=B6=D5=FE=B2=DF=D0=C5=CF=A2=A1=B7=CD=F8=C9=CF=CA=D5=B7= =D1=D4=D3=D6=BE > > =BB=B6=D3=AD=D4=EC=B7=C3=A3=BAhttp://zcxx.people.com.cn > > > > > > --__--__-- > > > > Message: 4 > > Date: Sun, 8 Dec 2002 00:42:55 -0500 (EST) > > From: Nicolas Christin > > To: supachoak chinnapong > > cc: ns-2 Mailing-List > > Organization: University of Virginia - CS Dept. > > Subject: [ns] GPRS crash (Was: Re: your mail) > > > > On Sat, 7 Dec 2002, supachoak chinnapong wrote: > > > > > I AM A STUDENT IN THAILAND.I SIMULATE GPRS BY RICHA > > > JAIN BUT IT CAN NOT. I USE 2 STEP THAT YOU RECOMMEND > > > BUT IT NOT WORK.IT SHOWS > > > > > > > > > segmentation faults > > > HOW I DO? PLEASE RESPONSE ME > > > > First of all, please refrain from leaving CapsLock on. > > > > Also, I explictly said that I hadn't tried out what > > I suggested. (Assuming you're referring to my post > > = http://mailman.isi.edu/pipermail/ns-users/2002-December/027848.html.) > > >From what you're writing, the patch may or may not have worked, = there > > is no way of knowing what caused this segfault, it can be a GPRS = problem > > or something else, all bets are off. > > > > When you get a segmentation fault with a contributed package (like = you > > seemingly have), the best thing is (again like I said in a previous > > post) to provide the author of the contributed module with the = script > > that generates the segfault (or a Bus Error, or whatever kind of = crash), > > so that (s)he can see if (s)he can reproduce the bug. In that case, = you > > would have to send your script to R. Jain. I am *not* the maintainer = of > > the GPRS package (for crying out loud, I don't even use that thing), = I > > was just trying to give general guidelines to someone who didn't = know > > how to use a patch. > > > > Now, if the original developer of the module doesn't reply or = doesn't > > provide any support, there may still be help available, albeit not > > guaranteed. The next best thing is to post to this list a gdb = backtrace > > showing exactly where the crash occured. For that type of matter, if = you > > want to stand a chance to get any valuable help from other folks on = this > > list, you'll need to have had ns compiled with the -g flag so that = your > > backtrace shows precisely which line (in the C++ code) caused the = crash. > > (A gdb backtrace without debugging symbols is almost useless.) Other > > people can then try to investigate the source. If you don't know = what a > > gdb backtrace is, you may want to read the gdb manual. Believe me, = it is > > time well-spent. > > > > As a final remark, as stated on the ns website, external packages = (i.e., > > contributed modules) are *not* supported by the ns developers team. > > (Which, to clarify a confusion that has been recurrent lately = judging > > from the amount of e-mails I get offline, I am *not* part of - = please > > don't email me directly, these emails go to /dev/null.) People = may/may > > not help, the easiest way to fix your problems is to take a deep = breath, > > learn as much as you can (Unix, C/C++, gdb) and try to fix the = problem > > yourself. Welcome to the open-source world. I know this sounds quite > > harsh, but it's the way it works. Of course, you always have the > > option to hire someone to fix your problems for you, but that type = of > > consulting work certainly doesn't come for free. > > > > Good luck, > > -- > > Nicolas > > > > > > --__--__-- > > > > Message: 5 > > Date: Sun, 8 Dec 2002 14:26:51 +0800 (CST) > > From: horner@peoplemail.com.cn > > To: deWaal@cs.uni-bonn.de > > Cc: ns-users@ISI.EDU > > Subject: [ns] help about ns-2 > > > > Christian de Waal : > > I am sorry to trouble you.I get the information below. > > I don;t know how you get the equation!From the ns-2 I know that it = just > adjusts the recv Threshold to change the range of sensing range. > > > > ---begin > > # the range calculations below assume two ray ground radio > > # propagation and that the antennas are 1.5m above the ground > > # (as it is the case for "OmniAntenna"s, see > > # tcl/lib/ns-default.tcl). > > if {$range <=3D 86.142470561432130598645681569524} { > > Phy/WirelessPhy set Pt_ [expr > > 5.3530386481240768322072823173423e-7*$range*$range] > > } else { > > Phy/WirelessPhy set Pt_ [expr > > 7.2138271604938271604938271604938e-11*$range*$range*$range*$range] > > } > > ---end > > > > ------------------------------------------------------------------ > > = =C8=CB=C3=F1=CD=F8=A1=B6=D5=FE=B2=DF=D0=C5=CF=A2=A1=B7=CD=F8=C9=CF=CA=D5=B7= =D1=D4=D3=D6=BE > > =BB=B6=D3=AD=D4=EC=B7=C3=A3=BAhttp://zcxx.people.com.cn > > > > > > --__--__-- > > > > Message: 6 > > Date: Sat, 7 Dec 2002 23:00:16 -0800 (PST) > > From: Rudhrakumar Venkatesan > > To: ns-users@ISI.EDU > > Subject: [ns] AODV Extension - New Packet type > > > > Hi, > > I am trying to extend AODV using GPS information. I needed to = create a > > new AODV packet header type together with the already existing 5 = packet > > header types. I added a new packet header type in aodv_packet.h, and tried > > to access it in the recv() routine. But even when I filled in the > > appropriate Packet header Type when I send the packet, I was not = able to > > receive it. When I did a switch based on the packet header type, it > > wouldn't recognise the packet. > > > > Did I miss something. Can someone throw some light on it? > > > > The questions I needed to be answered are: > > 1. How do U create a new packet header type for AODV ( under = PT_AODV) > > 2. How do you fill in the packet type in the packet header. > > > > I really appreciate any help in this regard > > > > Rudhra > > > > > > --__--__-- > > > > Message: 7 > > Date: Sun, 8 Dec 2002 16:07:08 -0530 (GMT) > > From: Kaushik Mitra > > To: ns-users@ISI.EDU > > Subject: [ns] queue length in wireless nodes > > > > > > > > > > hi ns-users, > > i am simulating a multihop network in a string topology. > > in this case how can i get the queue length in each of the > > nodes at run time? > > QueueMonitor is not working with the wireless case... > > > > can anyone help... > > thanks in advance. > > > > > > > > > > > > --__--__-- > > > > Message: 8 > > Date: Sun, 8 Dec 2002 14:41:47 +0200 > > From: "Semra YILMAZ" > > To: > > Subject: [ns] some questions > > > > Hi all ns users, > > > > I have few questions; > > > > 1. I think the default period of routing updates for DSDV routing protocol > is 3000msec. Is there any way to change this value in tcl code? > > > > 2. In multi-hop networks, what is the maximum hop number for DSDV, = DSR, > AODV and TORA? > > > > 3. For DCF, a mobile host firstly listens to the medium before it > transmits packet. If the medium is busy, this node adjust its NAV with > respect to the information in the packet which is already in the = medium. The > duration info for the packet to be transmitted is saved in the packet > header. Up to now it is OK. But if the host that has already sent the > packets cannot see the destination directly, there can be multi hops. = For > this condition, how do the other host which wants to transmit adjust = their > NAV? That is, are they adjusting according to only one hop (from = source to > neighbour host) or according to all route (from source to = destination)? Or > does it change according to routing protocol? > > > > 4. All nodes has a sending buffer and interface queue. What is the > difference between these two? And is there any buffer for received = packet or > is interface queue used for received packet? > > > > Any answer will be appreciated. > > > > Regards, > > > > Semra Yilmaz > > > > > > --__--__-- > > > > Message: 9 > > Date: Sun, 8 Dec 2002 22:29:11 +0800 > > From: "wang bin" > > To: "ns-users-admin@ISI.EDU" , > > "ns-users@ISI.EDU" , > > "ns-users@isi.edu" > > Subject: [ns] How can I know the connection number of queue/buffer? > > > > Hi, > > > > Can anyone help me with the basics of how to monitor the connection number > of queue/buffer? Suppose I have a topology as: > > > > (*)------------(*)------------(*) > > S1 R1 Sink > > > > I need to see how the connection number of queue/buffer in the = router is > changing with time.. > > > > Thanks a lot! > > > > Best regards, > > > > wang bin > > bwang@iipc.zju.edu.cn > > 2002-12-08 > > > > > > > > > > --__--__-- > > > > Message: 10 > > Date: Sun, 08 Dec 2002 18:32:04 +0000 > > From: aiden jennings <9927107@student.ul.ie> > > To: "'ns-users@ISI.EDU'" > > Subject: [ns] RE: demonstrating Mobile IP > > > > Hi, > > I'm running ns version 8 and i ca'nt seem to get the demonstration > > for Mobile IP working. I was wondering if anyone has a working = version > > of this script that is working and if so if i could get a copy of = it. > > Thank you in advance, > > Regards, > > Aiden > > > > > ---------- > > > From: aiden jennings > > > Sent: Thursday, December 05, 2002 1:18 PM > > > To: 'ns-users@ISI.EDU' > > > Subject: RE: Creating a Base Station???? > > > > > > Hello, > > > Could anyone please tell me the correct syntax for setting up a = base > > > station? > > > I am trying the following at the moment "set HA > > > [create-base-station-node 1.0.0]" but this gives me errors.Any > > > help would be greatly appreciated, > > > Regards. > > > Aiden > > > > > > > > > > > > > > --__--__-- > > > > _______________________________________________ > > Ns-users mailing list > > Ns-users@isi.edu > > http://mailman.isi.edu/mailman/listinfo/ns-users > > > > > > End of Ns-users Digest > > > > > Previous message: [ns] configQ command Next message: [ns] re: traffic generator. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ------=_NextPart_000_0009_01C2CE0C.5241AB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The manual=20 states, "... the configQ commands set the RED parameters for = each
virtual=20 queue. Note that as the precedence value increases, the = RED
parameters become=20 harsher."

Not sure what parameters are .. don't think it says = anything=20 about it in
that chapter .. maybe i need to look harder .. which page = or=20 section? or can
somebody just explain the parameters = again?

$qEC=20 configQ 0 0 20 40 0.02
$qEC configQ 0 1 10 20 0.10

$qEC = configQ=20 <queue number> <virtual queue number> <???> = <???>=20 <???drop
probability???>

Thanks ..


----------------------------
check ns manual chapter=20 'Differentiated Services Module'
(in the end of chapter)

On = Mon, 9 Dec=20 2002, A. Pauline Jacqueline wrote:

>
> = Hi,
>
> Can=20 some one explain me about the configQ command which is used to = specify
>=20 the RED parameters for the queues.
>
> Thanks,
>=20 Pauline
>
>
> ----- Original Message -----
> = From:=20 <
ns-users-request@ISI.EDU
>
> To: <ns-users@ISI.EDU>
> Sent: Monday, December 09, 2002 4:05 AM
> = Subject:=20 Ns-users digest, Vol 1 #430 - 10 msgs
>
>
> > Send = Ns-users=20 mailing list submissions to
> >
ns-users@isi.edu
>=20 >
> > To subscribe or unsubscribe via the World Wide Web,=20 visit
> >
http://mailman.isi.edu/mailman/listinfo/ns-users
<= FONT=20 face=3D"Times New Roman" size=3D3>> > or, via email, send a = message with=20 subject or body 'help' to
> > ns-users-request@isi.edu
> >
> > You can reach the person managing the = list=20 at
> >
ns-users-admin@isi.edu
> >
> > When replying, = please edit=20 your Subject line so it is more specific
> > than "Re: Contents = of=20 Ns-users digest..."
> >
> >
> > Today's=20 Topics:
> >
> >    1. What is = *rtt_seq_* ?=20 (Liangping Ma)
> >    2. Re: [Q] How to get = 802.11=20 throughput. (Michael Mercurio)
> >    3. About = the=20 energy model! (horner@peoplemail.com.cn)
> >    4. = GPRS crash=20 (Was: Re: your mail) (Nicolas Christin)
> >    = 5. help=20 about ns-2 (horner@peoplemail.com.cn)
> >    6. = AODV Extension=20 - New Packet type (Rudhrakumar Venkatesan)
> = >    7.=20 queue length in wireless nodes (Kaushik Mitra)
> = >    8.=20 some questions (Semra YILMAZ)
> >    9. How can = I know=20 the connection number of queue/buffer? (wang bin)
> = >   10.=20 RE: demonstrating Mobile IP (aiden jennings)
> >
> >=20 --__--__--
> >
> > Message: 1
> > From: = "Liangping=20 Ma" <maliangping75@hotmail.com>
> > To: ns-users@ISI.EDU
>=20 > Date: Sat, 07 Dec 2002 17:42:49 -0500
> > Subject: [ns] = What is=20 *rtt_seq_* ?
> >
> > Hi,
> >
> > Can = anyone=20 tell me what exactly the rtt_seq_ is ? And what it is for?
> = >
>=20 > The following is from tcp.h
> >
> > int = rtt_active_; /* 1=20 if a rtt sample is pending */
> > int rtt_seq_; /* seq # of = timed seg=20 if rtt_active_ is 1 */
> > double rtt_ts_; /* time at which = rtt_seq_=20 was sent */
> >
> > I am confused by these = comments.
>=20 >
> > And I tried tracing these variables, which gave the=20 following
> > (where rtt_ is the round-trip time, and the = timestamps=20 option is used)
> >=20 time           &nb= sp;     =20 rtt_  rtt_seq_  rtt_active_
> > 1.06096  0  = 0 =20 3  0   0.061 =20 0           1
> = >=20 1.13344  0  0  3  0   0.072 =20 1           1
> = >=20 1.14144  0  0  3  0   0.080 =20 3           1
> = >=20 1.20592  0  0  3  0   0.072 =20 3           1
> = >=20 1.21392  0  0  3  0   0.080 =20 7           1
> = >=20 1.22992  0  0  3  0   0.088 =20 7           1
> = >=20 1.27840  0  0  3  0   0.072 =20 7           1
> = >=20 1.28640  0  0  3  0   0.080 =20 15          1
> >=20 1.30240  0  0  3  0   0.088 =20 15          1
> >=20 1.31840  0  0  3  0   0.096 =20 15          1
> >=20 1.33440  0  0  3  0   0.104 =20 15          1
> >=20 1.35088  0  0  3  0   0.072 =20 15          1
> >=20 ...
> > There are no retransmissions or duplicate acks during = this=20 period of
> > simulation.
> >
> > Any help is = appreciated!
> >
> > Liangping
> >
>=20 >
> >=20 _________________________________________________________________
>= >=20 Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > =
http://join.msn.com/?page=3Dfeatures/featuredemail> >
> >
> >=20 --__--__--
> >
> > Message: 2
> > Date: Sat, = 7 Dec=20 2002 21:37:13 -0500 (EST)
> > From: Michael Mercurio = <lafcadio@bu.edu>
> > To: Park Seok Jong <
sj216@cais.kaist.ac.kr>
> > cc:
ns-users@ISI.EDU
> > Subject: Re: [ns] [Q] How to = get 802.11=20 throughput.
> >
> > I guess a question for you is = you're=20 looking for average throughput at
> > which layer?  If I = wanted to=20 compute the average throughput of 802.11, I
> > would be = counting bytes=20 of the layer above (IP perhaps), and forget
about
> > trying = to=20 count all the 802.11 MAC overhead.
> >
> > For = example, if I=20 sent 1000 bytes of IP data from node A to node B in X
> > = seconds, that=20 throughput calculation includes all the MAC overhead. If I
> > = wanted=20 IP overhead as well, I would count the packets at the = application
> >=20 layer.  To me, it all depends on your point of reference.
>=20 >
> > m
> > --
> > Michael = Mercurio
> >=20 lafcadio@bu.edu
>=20 >
> > On Sat, 7 Dec 2002, Park Seok Jong wrote:
> = >
>=20 > >
> > > hi,
> > >
> > > I = simulate=20 802.11 adhoc network, want to get overall throughput.
> > > = average=20 throughput / one link(say, from node 0 to node 1) can be
> = obtainded in=20 following way.
> > > some one (I forget his name. -.-; = )  has=20 posted this in this mailing
> list, and I fix it a little.
> = >=20 >
> > > protocol overhead.
> > > DIFS + = 3*SIFS +=20 contention window size*Slot time
> > > + RTS packet = Transmission=20 time(20 bytes)
> > > + CTS packet Transmission time(14=20 bytes)
> > > + ACK Transmission time(14 bytes)
> > = >=20 (transmission time include 192 bit PLCP header in basic rate, = 1Mbps)
>=20 > >
> > > upper layer protocol overhead(in case of = using CBR=20 traffic)
> > > UDP + IP + 802.11MAC =3D 8 + 20 + 34 = bytes
> >=20 > and lower layer PLCP head =3D 192bit.(24 bytes)
> > > = so, layer=20 overhead / one generated CBR pkt is (8+20+34) + 24 bytes.
> >=20 >
> > > throughput =3D data rate * (pkt size in byte * 8 = / data=20 rate ) /
> > > { (pkt size in byte * 8 / data rate) + layer = overhead=20 * 8 / data rate
+
> 192us + protocol overhead}
> >=20 >
> > > If above calculation is right, I can obtain avg=20 throughput / one
> directional link.
> > > this one is = almost=20 same with all nodes, because only variable is
> contention=20 windowsize
> > > and this one get to be trivial compared to = pkt size=20 when multiplied by
> slot time, 20us.
> > >
> = > >=20 Now, what I am curious is how I can obtain overall system = throughput.
>=20 > > to solve this problem, I count pkt from upper layer in recv=20 function
> > > of 802.11.cc, and count ack pkts in one node. = after=20 simulation, I got,
> > > say 1000 pkt of transmission in = this layer.=20 and got , say 800 ack pkts
> > > in one node. so, I conclude = effective throughtput is (throughput by
> > > above formula = * 800 /=20 1000.)
> > >
> > > but this conclusion make me = confused.=20 after I do this simulation, I
> > > got effective throughput = about=20 1.5 Mbps when data rate 2Mbps with CBR
> > > pkt size 2000 = bytes. I=20 read some e-mail discussing throughput of
> > > 802.11 = system, but=20 they said much lower throughput.
> > >
> > > can = anyone=20 tell me how I can calculate throughput of 802.11 system?
> >=20 >
> > > Best Wishes.
> > >
> > > = Park,=20 Seok Jong wrote from south korea.
> > >
> > = >
>=20 >
> >
> > --__--__--
> >
> > = Message:=20 3
> > Date: Sun, 8 Dec 2002 12:55:36 +0800 (CST)
> > = From:=20
horner@peoplemail.com.cn
> > To: ns-users@ISI.EDU
> > Cc:
> > Subject: = [ns] About the=20 energy model!
> >
> > hi!
> >  I am = sorry to=20 trouble you. Now I am newer of ns-2 and.Now I am seeing
the
> = chapter=20 of EnergyModel and Radio propagation models of ns-2!I am = confused
> that=20 the communication range is nnot ralation with the transmmision
>=20 energy!Just change the recv threshild!! it is meaning to change = the
>=20 transmission energymodel and the recv threshold is the same! maybe it = is
>=20 nosense question.?
> > please echo to the=20 e-mail:horner@peoplemail.com.cn
> >=20 ------------------------------------------------------------------
>= ; >=20 =C8=CB=C3=F1=CD=F8=A1=B6=D5=FE=B2=DF=D0=C5=CF=A2=A1=B7=CD=F8=C9=CF=CA=D5=B7= =D1=D4=D3=D6=BE
> >=20 =BB=B6=D3­=D4=EC=B7=C3=A3=BAhttp://zcxx.people.com.cn
> = >
> >
> >=20 --__--__--
> >
> > Message: 4
> > Date: Sun, = 8 Dec=20 2002 00:42:55 -0500 (EST)
> > From: Nicolas Christin = <nicolas@cs.virginia.edu>
> > To: supachoak chinnapong <
supachoak3711@yahoo.com>
> > cc: ns-2 Mailing-List <
ns-users@ISI.EDU>
> > Organization: University of Virginia - CS = Dept.
>=20 > Subject: [ns] GPRS crash (Was: Re: your mail)
> >
> = > On=20 Sat, 7 Dec 2002, supachoak chinnapong wrote:
> >
> >=20 >  I AM A STUDENT IN THAILAND.I SIMULATE GPRS BY RICHA
> = > >=20 JAIN BUT IT CAN NOT. I USE 2 STEP THAT YOU RECOMMEND
> > > = BUT IT=20 NOT WORK.IT SHOWS
> >
> > <snipping stuff that's = not very=20 explicit>
> >
> > > segmentation faults
> = >=20 > HOW I DO? PLEASE RESPONSE ME
> >
> > First of = all, please=20 refrain from leaving CapsLock on.
> >
> > Also, I = explictly=20 said that I hadn't tried out what
> > I suggested. (Assuming = you're=20 referring to my post
> >
http://mailman.isi.edu/pipermail/ns-users/2002-December/027848.h= tml.)
> > >From what you're = writing, the=20 patch may or may not have worked, there
> > is no way of = knowing what=20 caused this segfault, it can be a GPRS problem
> > or something = else,=20 all bets are off.
> >
> > When you get a segmentation = fault=20 with a contributed package (like you
> > seemingly have), the = best=20 thing is (again like I said in a previous
> > post) to provide = the=20 author of the contributed module with the script
> > that = generates the=20 segfault (or a Bus Error, or whatever kind of crash),
> > so = that (s)he=20 can see if (s)he can reproduce the bug. In that case, you
> > = would=20 have to send your script to R. Jain. I am *not* the maintainer = of
> >=20 the GPRS package (for crying out loud, I don't even use that thing), = I
>=20 > was just trying to give general guidelines to someone who didn't=20 know
> > how to use a patch.
> >
> > Now, if = the=20 original developer of the module doesn't reply or doesn't
> > = provide=20 any support, there may still be help available, albeit not
> >=20 guaranteed. The next best thing is to post to this list a gdb = backtrace
>=20 > showing exactly where the crash occured. For that type of matter, = if=20 you
> > want to stand a chance to get any valuable help from = other=20 folks on this
> > list, you'll need to have had ns compiled = with the -g=20 flag so that your
> > backtrace shows precisely which line (in = the C++=20 code) caused the crash.
> > (A gdb backtrace without debugging = symbols=20 is almost useless.) Other
> > people can then try to = investigate the=20 source. If you don't know what a
> > gdb backtrace is, you may = want to=20 read the gdb manual. Believe me, it is
> > time = well-spent.
>=20 >
> > As a final remark, as stated on the ns website, = external=20 packages (i.e.,
> > contributed modules) are *not* supported by = the ns=20 developers team.
> > (Which, to clarify a confusion that has = been=20 recurrent lately judging
> > from the amount of e-mails I get = offline,=20 I am *not* part of - please
> > don't email me directly, these = emails=20 go to /dev/null.) People may/may
> > not help, the easiest way = to fix=20 your problems is to take a deep breath,
> > learn as much as = you can=20 (Unix, C/C++, gdb) and try to fix the problem
> > yourself. = Welcome to=20 the open-source world. I know this sounds quite
> > harsh, but = it's the=20 way it works. Of course, you always have the
> > option to hire = someone=20 to fix your problems for you, but that type of
> > consulting = work=20 certainly doesn't come for free.
> >
> > Good = luck,
>=20 > --
> > Nicolas
> >
> >
> >=20 --__--__--
> >
> > Message: 5
> > Date: Sun, = 8 Dec=20 2002 14:26:51 +0800 (CST)
> > From: horner@peoplemail.com.cn
> > To: deWaal@cs.uni-bonn.de
> > Cc: ns-users@ISI.EDU
>=20 > Subject: [ns] help about ns-2
> >
> > Christian = de Waal=20 :
> >   I am sorry to trouble you.I get the = information=20 below.
> > I don;t know how you get the equation!From the ns-2 = I know=20 that it just
> adjusts the recv Threshold to change the range of = sensing=20 range.
> >
> > ---begin
> > # the range = calculations=20 below assume two ray ground radio
> > # propagation and that = the=20 antennas are 1.5m above the ground
> > # (as it is the case for = "OmniAntenna"s, see
> > # tcl/lib/ns-default.tcl).
> > = if=20 {$range <=3D 86.142470561432130598645681569524} {
>=20 >     Phy/WirelessPhy set Pt_ [expr
> >=20 5.3530386481240768322072823173423e-7*$range*$range]
> > } else=20 {
> >         = Phy/WirelessPhy=20 set Pt_ [expr
> >=20 7.2138271604938271604938271604938e-11*$range*$range*$range*$range]
>= ; >=20 }
> > ---end
> >
> >=20 ------------------------------------------------------------------
>= ; >=20 =C8=CB=C3=F1=CD=F8=A1=B6=D5=FE=B2=DF=D0=C5=CF=A2=A1=B7=CD=F8=C9=CF=CA=D5=B7= =D1=D4=D3=D6=BE
> >=20 =BB=B6=D3­=D4=EC=B7=C3=A3=BAhttp://zcxx.people.com.cn
> = >
> >
> >=20 --__--__--
> >
> > Message: 6
> > Date: Sat, = 7 Dec=20 2002 23:00:16 -0800 (PST)
> > From: Rudhrakumar Venkatesan=20 <
venkatru@ece.orst.edu>
> > To:
ns-users@ISI.EDU
> > Subject: [ns] AODV Extension = - New=20 Packet type
> >
> > Hi,
> >    = I am=20 trying to extend AODV using GPS information. I needed to = create
a
>=20 > new AODV packet header type together with the already existing 5=20 packet
> > header types. I added a new packet header type in=20 aodv_packet.h, and
tried
> > to access it in the recv() = routine. But=20 even when I filled in the
> > appropriate Packet header Type = when I=20 send the packet, I was not able to
> > receive it. When I did a = switch=20 based on the packet header type, it
> > wouldn't recognise the=20 packet.
> >
> > Did I miss something. Can someone = throw some=20 light on it?
> >
> > The questions I needed to be = answered=20 are:
> > 1. How do U create a new packet header type for AODV ( = under=20 PT_AODV)
> > 2. How do you fill in the packet type in the = packet=20 header.
> >
> > I really appreciate any help in this=20 regard
> >
> > Rudhra
> >
> = >
> >=20 --__--__--
> >
> > Message: 7
> > Date: Sun, = 8 Dec=20 2002 16:07:08 -0530 (GMT)
> > From: Kaushik Mitra <kmitra@ece.iisc.ernet.in>
> > To:
ns-users@ISI.EDU
> > Subject: [ns] queue length = in wireless=20 nodes
> >
> >
> >
> >
> > = hi=20 ns-users,
> >       i am = simulating a=20 multihop network in a string topology.
> > in this case how can = i get=20 the queue length in each of the
> >  nodes at run = time?
>=20 > QueueMonitor is not  working with the wireless case...
> = >
> > can anyone help...
> > thanks in = advance.
>=20 >
> >
> >
> >
> >
> >=20 --__--__--
> >
> > Message: 8
> > Date: Sun, = 8 Dec=20 2002 14:41:47 +0200
> > From: "Semra YILMAZ" <SYilmaz@hc.aselsan.com.tr>
> > To: <
ns-users@ISI.EDU>
> > Subject: [ns] some=20 questions
> >
> >  Hi all ns users,
> = >
>=20 > I have few questions;
> >
> > 1. I think the = default=20 period of routing updates for DSDV routing
protocol
> is = 3000msec. Is=20 there any way to change this value in tcl code?
> >
> = > 2. In=20 multi-hop networks, what is the maximum hop number for DSDV, = DSR,
> AODV=20 and TORA?
> >
> > 3. For DCF, a mobile host firstly = listens to=20 the medium before it
> transmits packet. If the medium is busy, = this node=20 adjust its NAV with
> respect to the information in the packet = which is=20 already in the medium.
The
> duration info for the packet to be = transmitted is saved in the packet
> header. Up to now it is OK. = But if=20 the host that has already sent the
> packets cannot see the = destination=20 directly, there can be multi hops. For
> this condition, how do = the other=20 host which wants to transmit adjust their
> NAV? That is, are they = adjusting according to only one hop (from source to
> neighbour = host) or=20 according to all route (from source to destination)? Or
> does it = change=20 according to routing protocol?
> >
> > 4. All nodes = has a=20 sending buffer and interface queue. What is the
> difference = between these=20 two? And is there any buffer for received packet
or
> is = interface=20 queue used for received packet?
> >
> > Any answer = will be=20 appreciated.
> >
> > Regards,
> >
> = > Semra=20 Yilmaz
> >
> >
> > --__--__--
> = >
>=20 > Message: 9
> > Date: Sun, 8 Dec 2002 22:29:11 = +0800
> >=20 From: "wang bin" <bwang@iipc.zju.edu.cn>
> > To: "ns-users-admin@ISI.EDU"=20 <ns-users-admin@ISI.EDU>,
> >    "
ns-users@ISI.EDU"=20 <ns-users@ISI.EDU>,
> >    "
ns-users@isi.edu"=20 <ns-users@ISI.EDU>
> > Subject: [ns] How can I know the connection = number of=20 queue/buffer?
> >
> > Hi,
> >
> > = Can anyone=20 help me with the basics of how to monitor the = connection
number
> of=20 queue/buffer? Suppose I have a topology as:
> >
> = > =20 (*)------------(*)------------(*)
> > =20 S1            = ; =20 R1            = ;=20 Sink
> >
> > I need to see how the connection number = of=20 queue/buffer in the router is
> changing with time..
> = >
>=20 > Thanks a lot!
> >
> > Best regards,
> = >
>=20 > wang bin
> >
bwang@iipc.zju.edu.cn
> > 2002-12-08
> = >
>=20 >
> >
> >
> > --__--__--
> = >
> >=20 Message: 10
> > Date: Sun, 08 Dec 2002 18:32:04 +0000
> = >=20 From: aiden jennings <9927107@student.ul.ie>
> > To: "'ns-users@ISI.EDU'"=20 <ns-users@ISI.EDU>
> > Subject: [ns] RE: demonstrating Mobile = IP
>=20 >
> > Hi,
> > I'm running ns version 8 and i ca'nt = seem to=20 get the demonstration
> > for Mobile IP working. I was = wondering if=20 anyone has a working version
> > of this script that is working = and if=20 so if i could get a copy of it.
> > Thank you in = advance,
> >=20 Regards,
> > Aiden
> >
> > > = ----------
>=20 > > From: aiden jennings
> > > Sent: Thursday, = December 05,=20 2002 1:18 PM
> > > To:
'ns-users@ISI.EDU'
>=20 > > Subject: RE: Creating a  Base Station????
> >=20 >
> > > Hello,
> > > Could anyone please tell = me the=20 correct syntax for setting up a base
> > > station?
> = >=20 > I am trying the following at the moment "set HA
> > >=20 [create-base-station-node 1.0.0]" but this gives me errors.Any
> = > >=20 help would be greatly appreciated,
> > > Regards.
> = > >=20 Aiden
> > >
> > >
> >
> = >
>=20 >
> > --__--__--
> >
> >=20 _______________________________________________
> > Ns-users = mailing=20 list
> >
Ns-users@isi.edu
> > http://mailman.isi.edu/mailman/listinfo/ns-users
<= FONT=20 face=3D"Times New Roman" size=3D3>> >
> >
> > = End of=20 Ns-users Digest
>=20 >
>
>
>






Previous = message: [ns]=20 configQ command
Next message: [ns] re: traffic generator.
Messages = sorted=20 by: [ date ] [ thread ] [ subject ] [ author=20 ]


------=_NextPart_000_0009_01C2CE0C.5241AB40-- From ghiddink@agere.com Thu Feb 6 05:16:41 2003 From: ghiddink@agere.com (Hiddink, Gerrit (Gerrit)) Date: Thu Feb 6 05:16:41 2003 Subject: [ns] Manet simulation: Signal-to-noise ratio Message-ID: <272DC08D5A30274C9A2707E51717E54F027B97D8@nl0030excuag01.agere.com> Hi, the simulator has no noise floor, but you can calculate a signal level from the packet's receive energy. This is stored in the packetstamp structure in the following way: int signalLevel = 10*log10(pktRx_->txinfo_.RxPr) You should subtract the noise level, which is about -90 dBm in a typical system. Regards, Gerrit > -----Original Message----- > From: Eva Kjær Troels [mailto:evakt@daimi.au.dk] > Sent: Wednesday, February 05, 2003 7:07 PM > To: ns-users@ISI.EDU > Subject: [ns] Manet simulation: Signal-to-noise ratio > > > > Hi! > > I am running manet simulations in ns2. I would like to make > changes to > AODV so that it will initiate a route repair before a route breaks. I > intend to do this by calculating the signal-to-noise ratio. I assume > that the signal-to-noise ratio should be calculated at the > MAC layer (?) > Does any of you have experience about this sort of thing? > > Hoping for a good answer :-) > > Eva Troels > From evakt@daimi.au.dk Thu Feb 6 05:16:57 2003 From: evakt@daimi.au.dk (=?ISO-8859-1?Q?Eva_Kj=E6r_Troels?=) Date: Thu Feb 6 05:16:57 2003 Subject: [ns] Wireless Broadcast Packet... I really need help here folks References: <00a001c2cd4c$3f81b970$2e08a8c0@technocom.com> Message-ID: <3E421AA9.7000004@daimi.au.dk> This is a multi-part message in MIME format. --------------060707030600000705080504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! I had a similar problem at some point. I could see in the trace file that a broadcast packet was sent (here is my code): Packet *pkt = allocpkt(); // Common header hdr_cmn *com_hdr = hdr_cmn::access(pkt); com_hdr->ptype() = PT_NOM; com_hdr->addr_type() = NS_AF_NONE; com_hdr->prev_hop_ = addr(); // IP header hdr_ip *ip_hdr = hdr_ip::access(pkt); ip_hdr->saddr() = addr(); ip_hdr->sport() = port(); ip_hdr->daddr() = IP_BROADCAST; ip_hdr->dport() = NOM_PORT; ip_hdr->ttl_ = ttl; but the packets were never received on the receiver side. I found out that a change to the ll.cc file (someone had made a posting) did the trick. void LL::recv(Packet *p, Handler* ) { ... if(ch->ptype_ == PT_ARP) arptable_->arpinput(p, this); else { hdr_ip *iphdr = HDR_IP(p); // Hack in order to get broadcast // packets delivered to the right agent if (iphdr->daddr() == IP_BROADCAST) { iphdr->daddr() = mac_->addr(); ch->next_hop() = mac_->addr(); } uptarget_ ? sendUp(p) : drop(p); } return; What it does is to change the IP_BROADCAST address to the address of the node. That way the addr demuxer did not throw the packet away. If the packet needs to be rebroadcast rememeber to change the address to IP_BROADCAST again before sending the packet downwards. Hope this is of help to you. Eva Bob Blakely wrote: >For example, I have 5 wireless nodes using a packet/agent structure derived >from the ping packet/agent structure. What I need to do is send one ping and >receive a response from every other node that directly hears it. So far I've >been unsuccessful in all my attempts to generate a "broadcast" (one to >many). Do any of you sharp fellows have the answer to my problem??? Can this >even be done? > >Regards, >Bob... >--------------------------------------------------- >"Beer is proof that God loves us >and wants us to be happy" > - Benjamin Franklin > > > > > --------------060707030600000705080504 Content-Type: text/plain; name="ll.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ll.cc" /* -*- Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -*- */ /* * Copyright (c) 1997 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in bina