Hi,
Daniel and me spent another day in the sysmocom office to go through
the PCU code. We finished clean-ups, made some simple manual tests
and looked at the traces.
We will work on the following items during the next weeks:
* For DL handling and multi-slot allocation more than one slot will
only be allocated _after_ the TBF is re-used. E.g. for a simple
download this might mean a single slot is used for the entire download.
Daniel made a prototype to send a packet downlink assignment directly
_after_ the assignment through the CCCH has completed. We manage to
run into a use after free in the TBF code but will work on it.
The issue is that the start of a TBF will take a bit longer. We
might want to add some heuristic to decide when or when not to do
it.
* Re-sending and window stalls. When the entire window has been sent
once, resending will start but when the ACK/NACK is arrived the
resending will conntinue. As it is more likely that frames have
arrived we should stop the resending and increase the window. This
will increase the throughput.
cheers
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Dear Andreas,
I went through the multislot allocation algorithm and cleaned and
structured the code in testable parts that take over parts of the
allocation and I have added a unit test for some of the allocation
cases (UL first, then DL.. e.g. due a RACH burst and then DL single,
UL and DL update).
Today morning I added a testcase that tests all PDCH combinations
and all MS Classes and verifies that an allocation takes place and
that the DL and UL first_common_ts do match. For (xxOxOOxO) and
MS_Class=5 this assert is wrong. The alloc/AllocTest of the
sysmocom/allocation-cleanups branch should show you this condition.
While reading the code I noticed the following things. Could you
please explain why these are problems or no problems.
* select_first_ts (it exists after the refactoring). It initializes
i and compares it but it will never increment it. This means that
the code can look at PDCHs _outside_ of the tx_range.
* first_common_ts handling. When assigning the DL tbf we pick a
first_common_ts but when the actual UL assignment happens there
might not be a free USF on the Uplink and at that point the phone
might not listen on the TS we think.
* Sum for Rx+Tx is not used. I see that in update_rx_win_max you
modify the window to make some room.
* select_ul_slots. "i" is not incremented in all cases which could
potentially lead to using slots outside of the tx_range. For the
MS Type == 1 handling you could introduce a different variable that
counts how many slots were used?
it would be nice if we could fix that during the 30C3.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Dear Ivan,
could you please have a look at the coverity issues in the gsm_rlcmac.cpp
routines?
Uninitialized scalar variable:
gsm_rlcmac.cpp:5321 ar.direction not initialized
gsm_rlcmac.cpp:5039 ar.direction not initialized
gsm_rlcmac.cpp:5155 ar.direction not initialized
gsm_rlcmac.cpp:4872 ar.direction not initialized
Just initialize it in csnStreamInit?
Out-of-bounds read:
gsm_rlcmac.cpp:5502 " Overrunning array "data->RLC_DATA" of 20 bytes
at byte offset 22 using index "i" (which evaluates to 22)."
gsm_rlcmac.cpp:5440 " Overrunning array "data->RLC_DATA" of 20 bytes
at byte offset 22 using index "i" (which evaluates to 22)."
Maybe just add an assert that dataNumOctets <= 20?
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Dear all,
so far the osmocom.org mailing lists have always been in a 'non-members
are manually moderated' mode. This has created a lot of work for manual
list moderation, where a lot of the messages caught are simply spam, and
only the occasional valid message is being received.
I'd like to thank the list moderators for taking care of this.
However, in more recent discussions, we were considering to move the
lists to a completely closed mode, i.e. postings would automatically be
rejected from non-members.
The automatic response would contain a description of how to subscribe
in 'nomail' mode, i.e. to subscribe in a way to be able to post to the
list, while still not receiving any incoming traffic. The latter should
be fine for occasional posters who don't want the bulk e-mail that goes
with a full/regular subscription.
Please provide feedback in case you disagree with that change. Unless
there is major opposition, we will likely transition to the 'closed'
mode within one month.
Thanks,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)