27 Nov
2013
27 Nov
'13
8:49 a.m.
Holger Hans Peter Freyther wrote:
Here is the starvation theory for the ping:
We have a LLC frame (or many queued up)... we schedule the polls and
at the final_ack indicate we decide to re-use the TBF. This means that
we will schedule another PACKET DOWNLINK ASSIGNMENT. But at the same
time we either want to honor the "rh->si" or want to schedule the ACK
due SEND_ACK_AFTER_FRAMES.
the idea behind priority of PACKET DOWNLINK ASSIGNMENT is that i do not
want the phone to switch back to idle mode. if i would ACK all uplink
blocks, the MS might switch back to idle mode immediately and will never
receive the PACKET DOWNLINK ASSIGNMENT.
when there was an ongoing downlink tbf, the phone keeps in transfer mode
until T3193 fires, so in case of a tbf re-use we can safely schedule a
PACKET UPLINK ACK/NACK prior PACKET DOWNLINK ASSIGNMENT.
So we more or less want to send "PACKET DOWNLINK
ASSIGNMENT" and the
"PACKET UPLINK ACK" at the same time (with more DL tbfs/traffic this
is getting more likely) but currently we will always prefer the PACKET
DOWNLINK ASSIGNMENT. This means that the uplink will starve (e.g. the
window stalled, rh->si means that the uplink will starve (the window
will stall, rh->si being set, etc).
once we sent PACKET DOWNLINK ASSIGNMENT we can ACK the uplink blocks
right afterwards. this should resolve the stalled window just a bit
later. this is my theory, but your tests showed that this does not work
as i would expect.