25 Nov
2013
25 Nov
'13
9:21 a.m.
On Mon, Nov 25, 2013 at 08:24:27AM +0100, Andreas Eversberg wrote:
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.
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.
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
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. 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.