[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ns] NS with GPRS-module - successfully passed GPRS-module internal test (example.tcl)





--
Free Dmitry Sklyarov ! 
http://www.freesklyarov.org

> -----Original Message-----
> From:	Robert Iakobashvili [SMTP:[email protected]]
> Sent:	Sunday, October 21, 2001 12:45 PM
> To:	[email protected]
> Cc:	[email protected]; [email protected]; [email protected]
> Subject:	[ns] NS with GPRS-module - successfully passed GPRS-module internal test (example.tcl)
> Importance:	Low
> 
> Yes, indeed.
> 
> I have prepared a distribution file, named ns-allinone-2.1b7a.tar.gz,
> size about 49 M with
> a README_FROM_ROBERT file.
> 
> You are welcome to tell me your anonymous ftp-site with write
> permissions, or any other account on your choice
> to make put to it.
> 
> Sorry, but internal security arrangements do not enable me to offer you
> a web site or ftp site for download.
> 
> What was done is :
> My OS is Solaris 5.7 on sparc, NS simulator version is
> ns-allinone-2.1b7a.
> 
> I tried to follow the procedure of Roger ([email protected]) and did the
> following:
> 
> STEP 1:
> 
> Dowloaded the all-in-one-installation of ns based on ns-allinone-2.1b7a
> and already incorporating the NOAH 
> extension from Jorg Widmer site
> http://www.isci.berkeley.edu/~widmer/mnav/ns-extension, named
> ns-wireless-2.1b7a.tar.gz .
> 
> 
> Another option is to copy manually files with Thomas Schwabe version of
> the NOAH extension from the same site into standard
> ns-wireless-2.1b7a.tar.gz distribution.
> 
> 
> KNOWN PROBLEMS (STILL PEOPLE  LIVE WTH THAT, see posted by Roger's
> correpondence)
> In both cases the compilation was o'key, but ./validate failed for the
> tests:
> 
> mip-adv-one, mip-adv-zero, mip-adv-multi failed with core dump;
> test-all-energy.tcl : dsdv, dsr, aodv - compute-routes problem ;
> dsdv-wired-cum-wireless has a meaningfull, but different output ;
> wireless1 and wireless2- configuration problems;
> wireless3 - core dump ;
> test-all-wireless-tdma.tcl : dsdv and dsr - configuration problem
> test-suite-wireless-shadowing.tcl : dsr - configuration and routing
> problem
> test-suite-wireless-diffusion.tcl : diff-rate-default, diff-rate-other,
> omnicast, flooding - configuration problems
> 
> 
> STEP 2. GPRS MODULE from Richa Jain
> 
> To the directories obtained from step 1 :
> 1. applied patch pgrs_patch ;
> 2. copied files from final_code directory ;
> 3. compiled successfully ./install once more;
> 4. setting of all environment var ;
> 
> Now the problem:
> 
> 'ns example.tcl' test from GPRS module has failed with:
> rlc-timers.cc:88: failed assertion 'busy_' ;
> 
> I commented the assert temporarily  as well as assert in ll-timers.cc:87
> 
> Modified output file instead of "gprs_err_acked.tr" to be
> "gprs_err_acked.tr.21.10.2001"
> 
> and tryed 'ns example.tcl'
> 
> cd to the directory with the GPRS package; cd gprs_doc
> 
> gzip -d gprs_err_acked.tr.gz
> 
> diff gprs_err_acked.tr FULL_PATH/gprs_err_acked.tr.21.10.2001
> 
> NO DIFFERENCES REPORTED
> 
> 
> The build was copied to directory ns-allinone-2.1b7a-GPRS
> 
> cded to directory and make uninstall ; make realclean or distclean or
> clean or veryclean
> 
> This file was added to the ns-allinone-2.1b7a-GPRS directory.
> 
> Please, pay attention to the above mentioned asserts, as I had no time
> to go inside the matter.
> 
	This is correct, I had to do the same. I wonder how it could ever work.
	I also had once a more or less working version of the gprs module lying around, but I think I hacked it to death ;-)
	Be warned, there are still problems with the gprs implementation:

	the bitrate of a link using 1 time slot is 1/0.000577 s/slot  /8 slots/frame *8 bit/byte *50 byte/slot = 86.6 kbit/s, for all 8 channels together this gives 693 kbps
	I think this is a little bit much. If you change it from 50 bytes per slot to 20 bytes per slot, it should be better

	fragmentation in the rlc layer: let's say you have a 120 byte packet. then the rlc layer will generate three fragments, 50 bytes, 50 bytes, 20 bytes, the remaining 30 bytes in the last packet stay empty. I don't think this is really good.

	Let's say you have two users, #1 uses time slot 1, #2 uses timeslot 2.
	Now you get 10 fragments from user #1. To send them you need 10 tdma frames. While sending these 10 fragments, no other timeslots can be used, so user #2 has to wait until #1 has finished, since there is only 1 queue between rlc and mac-gprs, so the 10 fragments of #1 have to be processed before other packets can be processed.

	before a transmission starts, no matter whether voice or data, arp packets are exchanged, is this correct ???

	Bye
	Alex