OpenBSC July 2020

openbsc@lists.osmocom.org

5 participants
14 discussions

Support for new SDR devices
by Xaver Zu 17 Aug '20

17 Aug '20

Hi all, What are the plans to expand support for new SDR devices? When I check the contents of osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1 devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be included in the master soon. At this point I see its addition in the fairwaves / libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next question. Would it be possible to add support for PCIe SDR from Amarisoft? Some information about SDR is here https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288 Based on the https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive… I tried to create support by myself. I've gotten into a state that some MS with weak requirements for signal quality and timing can connect. My branch is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle gr-osmosdr support is here https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR This osmo-trx is able to run for a few tens of seconds then it quits and I have to restart it, so I would need a deeper understanding of the timing and scheduling of processes within osmo-trx. Who should be a clock master SW stack or SDR device? I see a lot of log error messages as 0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0 <0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending IND CLOCK 1408899 or 0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver <0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device <0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start <0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR..., sample rate:1.08333e+06 <0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush <0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok: <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> radioInterface.cpp:202 [tid=140137328043776] Radio started <0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task 18522) set name: TxLower <0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task 18524) set name: RxUpper0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP POWERON 0' <0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task 18523) set name: RxLower <0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0 <0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested timestamp is not valid <0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task 18525) set name: TxUpper0 <0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960, length = 262144, time_start = 6765960, time_end = 6766960, data_start = 223320, data_end = 224320 <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:10976 ts:10960 hwts:6762040 <0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0 <0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in thread RxLower, requesting stop <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:13476 ts:13460 hwts:6762278 <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETRXGAIN 40' <0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB. <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETRXGAIN 0 40' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETPOWER 0' <0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60 dB. device:0x1f6e0e0 chan:0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETPOWER 0 0' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 0 5' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 0 5' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 1 7' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 1 7' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 2 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 2 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 3 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 3 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 4 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 4 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 7 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 7 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 13' <0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver... <0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver <0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device <0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop <0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped <0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped <0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device Yours XK1Zu

5 7

libosmocore / osmo_fd / select() / performance
by Harald Welte 21 Jul '20

21 Jul '20

Hi all, it has been coming up in at least two contexts recently: Select is showing up a lot in system-level profiles particularly on osmo-bts. This is hardly surprising, as select() is not particularly known for efficiency. It was used back in 2008 for the *BSC*, in a context where we were talking about 1-10 BTS with each no more than 1-2 TRX. Now we are using the same osmo_fd abstraction on the BTS, where the number of messages per second is much higher, particularly in osmo-bts-trx with its TRXD protocol, and particularly with higher number of TRX per BTS. There is an older feature request to introduce epoll support in https://osmocom.org/issues/1579 but unfortunately nobody has been finding the resources and/or time to implement it. Meanwhile, 1.5 years ago, the Linux kernel received a new sub-system called io_uring, which I would personally love to support. Here are some pointers for those who are interested: https://lwn.net/Articles/776703/ https://kernel.dk/io_uring.pdf https://lwn.net/Kernel/Index/#io_uring As unfortunately not everyone is using half-way recent kernels, we will likely have to fall back to epoll or something like that. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Osmocom scheduled outage on *2020-07-19 9am CEST*
by Harald Welte 19 Jul '20

19 Jul '20

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

OsmoCBC Status?
by Nick Jones 05 Jul '20

05 Jul '20

Hi all, Just wondering what the status of OsmoCBC is? I started compiling from source, but I couldn't find any docs on interfacing with it other than that it's via a HTTP REST API, If there aren't any docs are there packet captures or examples I can work from that'd be quicker than trying to reverse it from the source code, Happy to contribute some docs once I work it out, Cheers, Nick

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2020