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
This patch series fixes some build issues in libosmo-abis. The
failures occurred on a Debian jessie amd64 system, with libosmo* build
dependencies installed into distinct prefixes.
The first patch fixes the build-system wrt. out-of-tree builds, while
the second future-proofs the build system by enabling the
subdir-objects automake option (see commit message for details).
Hi,
On 30.04.2015 20:33, Jacob Erlbeck wrote:
> On 30.04.2015 20:01, Holger Freyther wrote:
> > Did ASAN help?
> No, since the data seems to be taken from then fc struct, so the memory area is
> valid. ASAN was enabled and didn't complain.
It wouldn't have helped here, but since ASAN is discussed in the context of memory errors, I'd like to check that it's been considered that ASAN's ability to detect and report memory errors may be being impaired by the use of talloc - particularly use after free bugs.
I took a very quick look at the talloc code, and it looks like the Valgrind memory poisoning macros are added, but not in a way that I can see as being active (missing #include of the Valgrind API headers + DEVELOPER needs to be defined). The 2.1.2 version of talloc looks to be perhaps more complete in this respect.
I'm not sure if ASAN can utilise the Valgrind macros though - perhaps something like Mozilla's approach to cover poisoning is needed: https://dxr.mozilla.org/mozilla-central/source/mfbt/MemoryChecking.h
Also I noticed that there is a --disable-talloc option to configure. I hoped this would fall back to libc malloc/free, but it actually disables use of the packaged talloc.c, and links with -ltalloc instead i.e. talloc isn't actually disabled:
if ENABLE_TALLOC
libosmocore_la_SOURCES += talloc.c
else
libosmocore_la_LIBADD += -ltalloc
endif
It may be better named --disable-builtin-talloc.
Kind Regards,
Mike
Hi
We
have configured OsmoNITB, OsmoBTS and OsmoTRX to run two transceivers
using UmTRX. But somehow when the spectrum is monitored, the only
frequency that is detected is the one TRX0 is tuned to. ARFCN set for
TRX1 is not detected i.e. TRX1 does not seem to be transmitting on the
specified frequency.
Can anyone please tell what possibly could be the issue?
Thanks & Regards,
Amber & Sarosh
Currently the DL sometimes hangs and sometimes a lot of messages
(still not able to send PDU) are logged. This is caused by an invalid
timer delay computation, setting msecs either to 0 or to some big value.
This is due to an '&' operator at the wrong place, accessing some
parts in fc instead of the first element of the list.
This commit fixes that issue.
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c
index 4c93b69..fe4fcca 100644
--- a/src/gb/gprs_bssgp.c
+++ b/src/gb/gprs_bssgp.c
@@ -628,7 +628,7 @@ static int fc_queue_timer_cfg(struct bssgp_flow_control *fc)
if (llist_empty(&fc->queue))
return 0;
- fcqe = llist_entry(&fc->queue.next, struct bssgp_fc_queue_element,
+ fcqe = llist_entry(fc->queue.next, struct bssgp_fc_queue_element,
list);
if (fc->bucket_leak_rate != 0) {
--
1.9.1