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
Good Afternoon,
last week at the sysmocom office Daniel and me continued to work on the
window handling. We have now a proper abstraction that allows us to unit
test the DL and UL window handling. The encode/decode of the RBB is now
compatible to itself.
While doing our manual tests (sending a big enough ICMP echo request)
we noticed that in the alloc algorithm b case the we get a lot of NACKs.
In the same setup (only alloc algorithm is changed) the A algorithm has
no NACKs.
I am now going to re-write the allocation handling. In terms of operation
on the first DL assignment (through the PCH) we can only use a singleslot
but when re-using the TBF we might go for multislot. In case the of UL
handling we could always try to use multislot assignments. Is this
understanding correct?
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
Good Morning,
we at sysmocom continued to add structure/architecture to the PCU
code and started to systematically test the code (using something
as simple as ICMP ping/reply)
Observations:
* "alloc algorithm b" has little (3kbit/s) more bandwidth than just
using the single slot assignment with CS4. There are also some
open coverity issues about this multi slot code.
* Congestion is badly handled. When using a ping that creates IP
fragments the LLC queue of the TBF gets so long that we expire
half the IP fragments before sending them. This means the MS at
the downlink never receives all the IP fragments of a PING.
We played with the BSVC-FLOW-CONTROL parameters but they don't
have any influence here. We have added counting of queue size
and calculation of the average queue delay to the LLC class.
One option is to drop packages based on the PDU lifetime and the
current queue delay.
$ sudo ping -s 1800 -i 0.1 10.23.42.6
(CS4, alloc-algorithm a) is enough to re-produce this issue.
* RLC V(Q) V(R) handling. It appears that after and before the
refactoring the Received Block Bitmap (RBB) is wrongly encoded. The
encode and decode are not compatible to each other (thanks to the
architecture sysmocom is adding to the code this can now be unit
tested!).
So as soon as we don't receive a frame from the UL. The send window
at the phone and the PCU is going out of sync.
After making changes to the window we have also witnesses that on
a fully received window V(Q) and V(R) were WindowSize away from
each other.
<0005> tbf.cpp:1579 UL DATA TFI=0 received (V(Q)=55 .. V(R)=60)
<0005> tbf.cpp:1624 - BSN 60 storing in window (55..118)
<0005> rlc.cpp:173 - Raising V(R) to 61
<0005> tbf.cpp:1690 - Scheduling Ack/Nack, because 20 frames received.
<0005> encoding.cpp:374 Encoding Ack/Nack for TBF(TFI=0 TLLI=0xfa45049d DIR=UL) (final=0) SSN=61
<0005> encoding.cpp:408 - V(N): "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR" R=Received N=Not-Received
This part might be something we broke but we will try to re-produce
with a unit test.
We will continue to work on unit-testing the RLC window handling if
anyone outside sysmocom interested in getting a more stable PCU?
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
