On Mon, Nov 25, 2013 at 08:24:27AM +0100, Andreas Eversberg wrote:
could this be an mtu issue at the phone? does the phone requests an uplink tbf to send a pong?
the first 10 pings going through and then nothing coming back? I don't think it is a MTU issue. I don't know what the root cause is but the structure of the code doesn't make it easy to find it.
In both cases it could be a scheduling issue (e.g. we don't schedule the UL Packet ACK/NACK).
in case of an ongoing uplink tbf, we ack/nack received or timed out uplink rlc/mac blocks by using a control block. even if there is an ongoing downlink tbf, all control blocks have priority over data blocks.
As I have already pointed out. Some control blocks can starve. I don't know if it does but it is where I will continue to have a look.
Is any of you aware of it? I had already highlighted that the scheduling is not fair. I wonder if we are seeing starvation (and will re-factor to be able to unit test this).
In terms of scheduling. For the SBA we are already having a reservation that we try to honor in multiple places. Maybe it is time to extend it and have more reservations?
uplink control messages are reserved in the tbf object (poll_fn). the sba control messages are reserved in a separate structure, since sba are not (or not yet) related to a tbf.
well. In the tbf you have:
else if (bts->sba()->find(trx->trx_no, ts, (fn + 13) % 2715648)) LOGP(DRLCMAC, LOGL_DEBUG, "Polling cannot be " "sheduled, because single block alllocation " "already exists\n");
But there is nothing that checks if another TBF is setting poll_fn to a frame that another tbf is already polling.