Files
osmo-pcu/TODO
Harald Welte a4e8c10a38 TODO: remove those that have obviously been implemented 5+ years ago
The TODO file hasn't seen any updates sicne 2014, while the code has
evolved.  I'm not sure about some of the topics, but at least several
can for sure be removed by now

Change-Id: I56581c9b2a08edb1b6d4dc53ad9eb6fdd1800a0d
2020-04-17 16:02:26 +00:00

35 lines
1.4 KiB
Plaintext

* Change functions with 100 parameters to get a struct as param
* Move move into the TBF class
* tbf/llc window code appears to be duplicated and nested in other
methods. This needs to be cleaned.
* Possible race condition:
When scheduling a Downlink Assignment on the UL-TBF we need to make
sure that the assignment is sent _before_ the final ack. With my fairness
changes it gets more likely that this event is trigerred.
* Optimize:
After receiving an ACK/NACK.. schedule another one if the window
is kind of stalled anyway. This way we avoid resending frames that
might have already arrived. It could increase the throughput..
Do not re-transmit after we got ack/nacked and where in the resending
mode... and increase the window.
<0004> tbf.cpp:907 - Sending new block at BSN 111
...
tbf.cpp:858 - Restarting at BSN 48, because all window is stalled.
...
tbf.cpp:1383 - V(B): (V(A)=59)"NNAAAAAAANAAAAANNAAAAAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXX"(V(S)-1=111) A=Acked N=Nacked U=Unacked X=Resend-Unacked I=Invalid
.. retransmitting the nacked.. and then the ones that migh have
already arrived
<0004> tbf.cpp:834 TBF(TFI=0 TLLI=0xd7b78810 DIR=DL) downlink (V(A)==59 .. V(S)==112)
<0004> tbf.cpp:840 - Resending BSN 111
Figure out scheduling issue. Why do we reach the 20 re-transmits and
stil haven't received the ACK/NACK? was it scheduled? The whole
scheduler could be re-worked to be more determestic.. and answer
questions like if it has been sent or not