diff options
authorHolger Hans Peter Freyther <holger@moiji-mobile.com>2014-01-16 10:11:57 +0100
committerHolger Hans Peter Freyther <holger@moiji-mobile.com>2014-01-16 10:11:57 +0100
commita09e33cdeb4a128e2338f724e794369b679f8f3b (patch)
parente5109ba1f0b6349c6d6fc56198551ab532685896 (diff)
TODO: Update the todolist with some musings...zecke/pcu-next
1 files changed, 24 insertions, 0 deletions
diff --git a/TODO b/TODO
index 9f994ea..a449398 100644
--- a/TODO
+++ b/TODO
@@ -16,3 +16,27 @@
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