From a09e33cdeb4a128e2338f724e794369b679f8f3b Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Thu, 16 Jan 2014 10:11:57 +0100 Subject: [PATCH] TODO: Update the todolist with some musings... --- TODO | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/TODO b/TODO index 9f994ea0..a449398c 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