Change in osmocom-bb[master]: trxcon/scheduler: check TDMA frame order, drop out of order bursts

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

fixeria gerrit-no-reply at lists.osmocom.org
Thu Jul 9 21:21:41 UTC 2020


Hello neels, laforge, Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmocom-bb/+/19201

to look at the new patch set (#4).

Change subject: trxcon/scheduler: check TDMA frame order, drop out of order bursts
......................................................................

trxcon/scheduler: check TDMA frame order, drop out of order bursts

When running together with fake_trx.py (mostly used back-end), it
is currently possible that Downlink bursts are received in a wrong
order if more than one transceiver is configured (multi-trx mode).

This is how it looks like:

  DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0
  DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1
  DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0
  DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2
  DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0
  DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3

  DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0
  DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F
  DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0
  DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1

  DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0
  DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
                               since the last processed fn=633 (current fn=632)

so here a burst with TDMA fn=633 was received earlier than a burst
with TDMA fn=632.  The burst loss detection logic considered the
latter one as lost, and substituted it with a dummy burst.  When
finally the out-of-order burst with TDMA fn=632 was received, we
got the large number of allegedly elapsed frames:

  ((632 + 2715648) - 633) % 2715648 == 2715647

Given that late bursts get substituted, the best thing we can do
is to reject them and log an error.  Passing them to the logical
channel handler (again) might lead to undefined behaviour.

Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Related: OS#4658, OS#4546
---
M src/host/trxcon/sched_trx.c
1 file changed, 26 insertions(+), 5 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/01/19201/4
-- 
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/19201
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Gerrit-Change-Number: 19201
Gerrit-PatchSet: 4
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200709/e4f06da6/attachment.htm>


More information about the gerrit-log mailing list