OpenBSC August 2020

openbsc@lists.osmocom.org

9 participants
23 discussions

ttcn3-bsc-test-latest status
by Neels Hofmeyr 13 Aug '20

13 Aug '20

I recently broke ttcn3-bsc-test-latest for a couple of builds, which is fixed now. Still it appears like some 'latest' tests remain damaged, but that is actually not the case. Here a summary of those that look like failures but are expected: TC_chan_rel_rr_cause: the test is new and tests a feature not implemented in 'latest' yet. TC_chan_rqd_emerg_deny: the test is new and I'm not sure of its 'latest' status. TC_si2quater_2_earfcns, TC_si2quater_3_earfcns: osmo-ttcn3-hacks just now merged a patch that also tests EARFCN presence in a Channel Release message. Since 'latest' still has a bug that causes only the first EARFCN to appear in that message, these two tests now fail in 'latest'. TC_cbsp_emerg_write_bts_cgi_cchan: This used to fail, then during the massive failures it suddenly passed for a bit, and now fails again. The passes must have been flukes. ~N

1 0

build trigger thunder cloud
by Neels Hofmeyr 12 Aug '20

12 Aug '20

Today I noticed that osmo-msc-master was being built several times in a row and I found there are multiple redundant ricocheting downstream builds of the same original upstream build timer. All of: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/ show: Started by upstream project master-libosmocore build number 1624 And then there are: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/ showing: Started by upstream project master-libosmo-abis build number 2611 So there are two timers launching master-libosmocore and launching master-libosmo-abis, and each of these cause multiple downstream build triggers of osmo-msc. Then there is also the osmo-msc timer, independently launching more nightly master-osmo-msc builds. It is not necessary to depend these builds on each other, because none of them depends on artifacts built in another job, each of them in turn builds the entire chain of libosmocore up to that build's target project. Upon a libosmocore *code change*, it makes sense to trigger downstream builds, but not when caused by a timer or for other jenkins trigger or user reasons. I vaguely remember discussing this before, but now I realize we could solve this and have less redundant builds: Do not configure libosmocore to trigger downstream builds of master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on the master-libosmo-abis build job config, making a patch-merge to the gerrit libosmocore.git cause a master-libosmo-abis build. At that point, jenkins timers no longer cause downstream builds, but merges to master on upstream git repositories do still cause builds. (maybe there is also a normal git SCM way that doesn't require gerrit.osmocom.org?) For projects like osmo-msc, we would add multiple projects as upstream git repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh, osmo-mgw, ... Basically all of the projects with more than one dependency get retriggered redundantly every night, some doing their entire build matrix over several times for no good reason. I'm not sure that it's really worth the effort, but I thought I'd mention it since seeing so many redundant builds on various osmo source trees at night seems avoidable stupidity. Should someone spend cycles to implement this? ~N

1 0

osmo-bts-trx + osmo-trx: dummy burst filling
by Vadim Yanitskiy 01 Aug '20

01 Aug '20

Hi all, as some of you may know, I am currently working on baseband frequency hopping implementation for osmo-bts-trx (see OS#4546). I've already submitted more or less final implementation to Gerrit [1], and in general it works fine [2]. The idea is quite simple: you have several RF carriers (transceivers) with fixed frequencies, so on hopping timeslots osmo-bts-trx distributes bursts between them according to the configured hopping sequence. However, when it comes to hopping timeslots on C0, the burst distribution algorithm gets a bit more complicated. The problem is that on C0 the BTS has to maintain constant power level, even if there is nothing to transmit, so the phones can detect it reliably during the power scan. This is achieved by sending dummy bursts. When frequency hopping is not in use, the scheduler in osmo-bts-trx sends a dummy burst immediately. When it is in use, sending dummy bursts needs to be postponed until all transceivers are processed, because some other transceiver might need to send a normal burst on the frequency of C0, and there would be no need to send a dummy burst in that case. So I came up with [3] (any comments regarding potential optimizations and further improvements are welcome). While working on this, I stumbled upon the burst filling feature in osmo-trx [4], that is disabled by default. If enabled, osmo-trx would be sending dummy bursts itself, so there is no need to send them from osmo-bts-trx, and thus no need to complicate the burst distribution logic. I am now wondering why don't we enable this feature by default? From the VTY reference: > Send a dummy burst when there is nothing to send on C0 (TRX0) and > empty burst on other channels. Use for OpenBTS compatibility only, > don’t use with OsmoBTS as it breaks encryption. it's unclear how sending dummy bursts would break encryption... [1] https://gerrit.osmocom.org/c/osmo-bts/+/19030 [2] https://www.youtube.com/watch?v=tGMVNYo9s7E [3] https://gerrit.osmocom.org/c/osmo-bts/+/19029 [4] http://ftp.osmocom.org/docs/latest/osmotrx-vty-reference.pdf#subsection.1.9… Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2020