Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
Otherwise you have to restart BTS or at least break the RSL connection
to apply the change.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
The code to do that doesn't belong to the control interface, so abstract it
out
to a separate function gsm_bts_set_system_infos().
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Changes:
* Apply change even if the supplied value is odd, just warn that it is
rounded.
Previously the value was not set at all, which may have lead to a
situation when
a user thinks the BTS operating at low power, while it is running full
power.
* Apply change even if the supplied value is higher than the 24dB maximum
suggested by the standard, just warn about this.
UmSITE and probably other SDR based BTS support much wider power
regulation range.
* Apply change to the BTS over OML immediately.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
Good afternoon!
In libbsc/bsc_init.c we have the following case:
case GSM_BAND_900:
if (bts->c0->arfcn < 1 ||
(bts->c0->arfcn > 124 && bts->c0->arfcn < 955) ||
bts->c0->arfcn > 1023) {
LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n");
return -EINVAL;
}
break;
3GPP 45.005, table 2-2 gives valid channel numbers as:
P-GSM900 -> 1-124,
E-GSM900 -> 0-124 and 975-1023
R-GSM900 -> 0-124 and 955-1023
ER-GSM900 -> 0-124 and 940-1023
The code looks to bounds check ARFCN closest to R-GSM900, but omits ARFCN 0.
Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history?
Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)?
The other band checks look correct.
Kind Regards,
Mike
PS: osmo-arfcn is okay with ARFCN 0:
$ ./osmo-arfcn -a 0
ARFCN 0: Uplink 890.0 MHz / Downlink 935.0 MHz