Bug #4366
openCreate testsuite to test osmo-bts-trx+osmo-trx under high channel load (w/ RACH correlation)
0%
Description
This ticket is an incremental step over #4365. Basically the same test, jusr with some slight modification in the RSL CHAN ACT.
As RACH correlation is particularly expensive, I having hand-over on too many TCH active simultaneously will create CPU load spikes that any resource constrained system may not be able to take.
When a TCH is activated for hand-over, then the BTS instructs the PHY (OsmoTRX) to perform RACH correlation.
On L1SAP the RACH SAPI gets activated for the TCH. This is required as the first thing during incoming handover is the MS sending a RACH request so we can establish the initial TA.
RACH correlation is relatively expensive, as you don't know where it will happen in the time domain, so you need to do the same correlation dozens or hundreds of time within one uplink block, as you don't know where exactly it starts.
So in theory, activating many channels with RACH detection (RSL CHAN ACT for handover) should create the highest load on the PHY/TRX.
It would be interesting to do a test series even on x86 to see the CPU
utilization difference between scenarious like
14x TCH/H without RACH
14x TCH/H with RACH
7x TCH/F without RACH (maybe even FR/EFR/AMR is different?)
7x TCH/F with RACH (maybe even FR/EFR/AMR is different?)
or, if really adventurous, maybe even many SDCCH (we typically only have
1xSDCCH4 or 1xSDCCH8, but what if somebody only wanted to do SMS
services and hence configure the BTS for 7xSDCCH8 and then actually open
56 SDCCH? maybe that's even more load?)
Related issues