Summary of osmo-pcu failures/defects
Holger Hans Peter Freyther
hfreyther at sysmocom.de
Mon Nov 25 08:21:08 UTC 2013
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 "
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 at 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
More information about the osmocom-net-gprs