Fairness of sched_poll

Holger Hans Peter Freyther hfreyther at sysmocom.de
Thu Oct 17 14:50:50 UTC 2013


On Thu, Oct 17, 2013 at 03:17:17PM +0200, Andreas Eversberg wrote:

> it is some kind of a hack. since we don't get bad frame indications from
> bts for sure, i had to find a way to detect when frames have not been
> received. normally the pcu_rx_data_ind function should call the timeout
> function in case of a bad frame. in this case the timeout function
> should actually be renamed to some kind like gprs_rlcmac_bfi(). if there
> is a way to fix bad frame indications from sysmobts, i would change the
> osmo-bts-trx code too, so both will send bad frame indications and we
> can get rid of this hack.

Andreas,

the point is not about if polling should be used but how the code
is structured. E.g. why does the polling belong into the part of
pcu_rx_data_ind?

For me the responsibility of pcu_l1if.c is to communicate with the
BTS (dispatch indications, send primitives, handle the socket). I
would have never expected this code to be in a function with that
name.

Mixing code like this is problematic because:

* It is increasing the depdency between the pcu_l1if and the
  rest of the code. This means understanding the PCU is more
  complicated and modification is more difficult/dangerous


* It makes it more difficult to test the different parts. E.g. a
  very basic test for pcu_rx_time_ind would be that the current
  fn is updated. Currently this can not be tested.



-- 
- 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 mailing list