Multislot allocation failures and defects

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.

Andreas Eversberg andreas at eversberg.eu
Wed Jan 15 12:58:27 UTC 2014


Holger Hans Peter Freyther wrote:

hi holger,

thanx for merging the patches.

> @@ -409,7 +409,6 @@
>  PDCH[5] is first common for DL
>  PDCH[5] is used for UL
>  PDCH[6] is used for UL
> -PDCH[7] is used for UL
>  PDCH[5] is control_ts for UL
>  PDCH[5] is first common for UL
>  PDCH[5] is used for DL
> @@ -420,7 +419,6 @@
>  Testing jolly example
>  PDCH[1] is used for UL
>  PDCH[2] is used for UL
> -PDCH[3] is used for UL
>  PDCH[1] is control_ts for UL
>  PDCH[1] is first common for UL
>  PDCH[1] is used for DL
>
> so it appears that the multislot algorithm started to not assign/use
> the last timeslot. Could you please have a look at that?
>   
If you look at patch "alloc_algorithm_b: Increment 'i', so allocated TS
will not exceed tx_range", i added the missing "i++" in for-loops.
inside one loop there is an incrementation (already), which needs to be
removed:

-		if (++i == ms_max_txslots) {
+		if (i+1 == ms_max_txslots) {

I compared the output of the AllocTest with the expected output. Now they match.


regards,

andreas

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-alloc_algorithm_b-Remove-obsolete-i-incrementation-f.patch
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20140115/90bd9ecf/attachment.ksh>


More information about the osmocom-net-gprs mailing list