Today I noticed that the Osmocom_Sanitizer build has been broken for a long
time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault
of the way the Osmocom_Sanitizer builds:
When I build libosmocore with --enable-sanitize, everything works out. When I
instead build with `make CFLAGS+="..."', some CFLAGS are dropped and the build
fails.
The working commandline is:
./configure --enable-sanitize
make V=1
[...]
gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -g -O2 -fsanitize=address -fsanitize=undefined -msse3 -msse4.1 -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o
The failing one is:
./configure
make CFLAGS+="-fsanitize=address -fsanitize=undefined" V=1
[...]
gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -fsanitize=address -fsanitize=undefined -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o
i.e. in the failing build, these cmdline args are missing:
-O2
-g
-msse3
-msse4.1
So it seems that the CFLAGS+="stuff" is not working as intended.
The alternative is to build with the ./configure --enable-sanitize, which I
added at some point. But not all libs have this switch, AFAIR. I have added
the --enable-sanitize configure option to libosmocore, and asked others to
follow up in other repositories in the same fashion. I think this hasn't worked
out everywhere yet.
Does it make sense to refresh the sanitize build effort?: switch the
Osmocom_Sanitizer build to using this configure flag and add it where it is
missing.
But I guess we should instead add the sanitize switch to each individual build
script for the various *osmo* build jobs and switch off the Osmocom_Sanitizer
build instead.
I repeat myself, but adding --enable-sanitize is not a lot of effort.
See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da5…
I created https://osmocom.org/issues/2330
~N
Dear all,
I would like to know your opinions about some optimizations
of Viterbi decoder, which were already discussed previously.
First of all, I would like to share some benchmarking results.
I used the test cases ("osmo-conv-test"), written by Tom Tsou,
to ensure that SIMD optimization is integrated correctly. And,
shortly speaking, the results are almost equal. Older version
of decoder is a little bit faster, but I think it's because
one is being compiled with "-march=native".
Returning back to the subject, as we allocate and free some
memory on every osmo_conv_decode_acc() call, what may happen
very frequently and tear down performance on some hardware,
there was the following suggestions:
1) Use static memory allocation where it's possible.
2) Use talloc for dynamic allocation.
3) Internal caching:
Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote:
> Internal caching was in the original implementation, but
> stripped from the submitted version mainly for simplicity
> and avoiding the need for global variables, though we seem
> to be having that discussion anyway ;-) The trellis values
> can be cached based on pointer or hashed code. That works well
> until threading is involved and cache access needs to be locked.
> Those are features I need, but can probably be ignored in this
> case.
>
> Again, I think the API should be kept intact. Internal caching,
> can be a topic for later discussion.
So, I am open for your ideas, opinions and remarks.
With best regards,
Vadim Yanitskiy.
Hi Philipp,
I have rebased the 'aoip' branch onto openbsc master. A test by the
osmo-gsm-tester of this state was successful. Pending is to also verify voice
and all of 3G still works there (will then update vlr_2G and vlr_3G branches).
Some commits have been amended to,
a) adjust libsmpp changes to use vlr_subscr,
b) fix the msc_vlr unit tests after your rename of a_tx() and a_page()
(don't really know why I didn't hit that earlier).
c) add one comment
So beware, if you rebase your most recent patches onto the 'aoip' branch, git
may want to apply a few patches again because they slightly differ, even though
their commit logs are identical. You need to sanity-check with 'rebase -i'.
~N
Hi Tom and others,
in our testing setup, we have sporadic failures (~2 out of 10 times) with:
DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx
What would be possible reasons for this failure, and how can we go about fixing
it? Some more logging around it:
20170614032014399 DRSL <0000> rsl.c:2333 (bts=0,trx=0,ts=0,ss=2) Fwd RLL msg EST_IND from LAPDm to A-bis
20170614032018533 DL1C <0006> scheduler_trx.c:1451 PC clock skew: elapsed uS 4136730
20170614032018533 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx
20170614032018533 DL1C <0006> scheduler.c:240 Exit scheduler for trx=0
20170614032018533 DL1C <0006> scheduler.c:216 Init scheduler for trx=0
20170614032018533 DOML <0001> oml.c:280 OC=RADIO-CARRIER INST=(00,00,ff) AVAIL STATE OK -> Off line
[...]
Shutdown timer expired
(We're using an external 10MHz OCXO timing source)
It appears there's four seconds of nothing from osmo-trx?
Most curious is that the next run will be completely fine, until some time
later we get this same failure.
We wait until osmo-trx logs
-- Transceiver active with 1 channel(s)
and then we "immediately" or up to a second later launch osmo-bts-trx. Would it
help to give it more grace time??
Thanks!
~N
Neels,
> What would be possible reasons for this failure,
> and how can we go about fixing it?
As I know, this happens when scheduler detects, that
system time is changed. For example, it might be caused
by NTP time correction.
- Do you have NTP enabled?
- Have you specified process realtime priority?
With best regards,
Vadim Yanitskiy.
Hi,
Is it possible to perform end-to-end testing like voice calls, sms etc with current osmo-gsm-tester version.
I do not see any suites for voice call testing in the suites directory.
Thanks
Sudhanthiradasan R
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
Max,
you fixed the coverity issue in https://gerrit.osmocom.org/2885, but a few
lines above that, there is another +1 that seems one +1 too many:
if (m_id_len > MAX_BTS_FEATURES/8 + 1) {
LOGP(DNM, LOGL_NOTICE, "BTS%u Get Attributes Response: feature vector is truncated to %u bytes\n",
bts->nr, MAX_BTS_FEATURES/8);
m_id_len = MAX_BTS_FEATURES/8;
}
I can't claim I understand why this size check is necessary on top of the other one,
but certainly "> MAX_BTS_FEATURES/8 + 1" doesn't match setting
"m_id_len = MAX_BTS_FEATURES/8".
~N
Dear all,
osmo-gsm-tester is currently capable of setting up an entire network
with one or more BTSs, Modems, NITB, etc. and test signaling + SMS.
Voice testing has always been on the wishlist, but further down on the
TODO list. One issue here is that
a) many modems don't do voice at all (data-only modems for laptops)
b) some modems expose voice only as analog audio (difficult to interface,
would require custom hardware next to the modem, e.g. using USB
soundcard, calibrate the levels, ...)
c) some modems expose the voice as PCM bus. Similarly, would require
some external codec chip and/or USB soundcard or the like, plus a
custom circuit
d) some modems expose voice as "GSM codec frames over UART" or other
highty proprietary formats
e) some modems expose voice as USB audio device. Most convenient, but
only found in some Qualcomm LE based devices such as Sierra Wireless
or Quectel.
Over the weekend I was thinking of yet another method to make this much
simpler: Every phone is supposed to include a voice loop-back mode. In
this mode, the phone siply loops back all voice frames received in the
downlink and sends them back in the uplink. This functionality is
mandatory by the spec, and used to test the receiver performance of the
phone during development, manufacturing and service. IT is specified in
3GPP TS 44.014
(http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144…)
which used to be GSM TS 04.04
(http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101…)
before.
The idea is that one puts a special "Test SIM" (as specified in TS
51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this
context) into the phone, and then sends some specific commands on Layer3
to activate the loop.
So if we can activate that loop-back functionality from the Osmocom
stack, we could test if we get back the same voice data that we send in
downlink (minus some occasional bit error, but those should be super low
given we're operating omso-gsm-tester over coaxial cabling between MS and
BTS).
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Neels,
> If you submitted a patch for it I would probably +vote it.
Not yet.
> I guess it would actually be a whole bunch of patches,
> a common part in libosmocore and using it in each osmo* program?
Probably, it would be a whole bunch of patches for osmo*
programs only. I was wondering about modifying libosmovty
to enable a new VTY command in all projects, like Harald did
in osmo-fsm implementation. But in case of FSM, all state
machines are being registered before use, so libosmovty
"knows" about them.
What is impossible in case of talloc contexts right now.
Of course, we can write a new function and register every
root talloc context using it. What about that?
Regarding to the commands to add, I think
show ctx all - Show list of all registered talloc contexts.
show ctx NAME - Find specified context and call talloc_report_full.
With best regards,
Vadim Yanitskiy.
2017-06-01 4:34 GMT+07:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>:
> re "what do you guys think about having a special VTY command to get a
> talloc report?"
>
> If you submitted a patch for it I would probably +vote it. I guess it would
> actually be a whole bunch of patches, a common part in libosmocore and
> using it
> in each osmo* program?
>
> ~N
>
>
Hi,
The osmocom software that I do not install via apt but build myself gets
installed in $HOME/usr and I do things like:
export PATH="${PATH}:${HOME}/usr/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib"
export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig
MANPATH="${MANPATH}:${HOME}/usr/man"
Therefore I don't have to install to a destination outside my home
directory which in turn means I can avoid some sudo calls.
But that actually does not matter so much, you can mentally substitute
$HOME with '/' and append '/local' in the following if you want.
I don't install to $HOME/usr directly but use stow for 'managing' the
installations, so an installation goes like this:
$ mkdir -p $HOME/src/telco/osmo/libosmo-abis
$ cd $HOME/src/telco/osmo/libosmo-abis
$ git clone git://git.osmocom.org/libosmo-abis
$ autoreconf -i
$ ./configure --prefix=$HOME/usr/stow/libosmo-abis
$ make
$ make install
$ STOW_DIR=$HOME/usr/stow stow libosmo-abis
This has two advantages:
* Good visibility of what is installed by a package.
$ tree $HOME/usr/stow/libosmocore
* Possibility of uninstalling a package even if the Makefile is not
present.
For me those two advantages outweigh the small additional effort of
using stow.
Because of that workflow I sometimes run into situations in which make
runs fail because either header files are not found during compilation
or libraries are not found during linking. The reason is that autotools
variables pointing to pkgconfig supplied directories point to a
destination under the prefix path with which configure was called. If a
dependency was not mentioned in a Makefile.am the required files are not
found because the other dependencies are in other directories.
For a system on which the osmocom-own dependency libs are installed in
distinct directories, current openbsc master HEAD requires the attached
patch for a build to succeed.
I admit that in most situations the dependencies are installed in the
same directory so this does not matter, but it is still a small bug.
Therefore I propose to modify the jenkins build scripts so that they use
distinct, stow managed directories for the dependencies. That should
help to detect oversights, although admittedly developers would have to
adapt their workflows to use stow as well in their daily hacking.
Otherwise an oversight would be detected by jenkings and not locally
which in turn would require additional cleanup commits which is not so
nice.
What is your gut feeling? Does the increased correctness of Makefiles.am
contents justify the (IMO rather small) additional effort of using stow?
Kind regards,
-Alex
