https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-12-15T12:37:36ZOpen Source Mobile CommunicationsOsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68262017-12-15T12:37:36Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2761">Bug #2761</a>: osmo-gsm-tester: add test case: Test 2nd trx is correctly used</i> added</li></ul> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68282017-12-15T14:06:43Zlaforge
<ul></ul><p>On Fri, Dec 15, 2017 at 12:30:47PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>We also lack multiple TRX support in osmo-bts-trx.</p>
</blockquote>
<p>I presume you want to say "in the osmo-gsm-tester support for osmo-bts-trx" ?</p>
<blockquote>
<p>It should not be difficult to add support for it. We basically require<br />to launch a new osmo-trx process (if launch_trx option is enabled) for<br />each TRX configured.</p>
</blockquote>
<p>The normal method used so far AFAIK is to run two soft-TRXs within one<br />osmo-trx instance. This will create two ARFCN carriers inside the<br />spectrum of the USRP. That's what the "-c 2" option of osmo-trx would<br />do. This is similar to osmo-bts-lc15 or osmo-bts-octphy where we run<br />two phy_instances in one phy_link.</p>
<p>I'm not sure if the "run one phy_instance in each phy_link of two<br />separate osmo-trx instances" would work without significant changes to<br />osmo-trx, whcih I believe is out of scope here.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68302017-12-15T14:46:01Zpespin
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Fri, Dec 15, 2017 at 12:30:47PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>We also lack multiple TRX support in osmo-bts-trx.</p>
</blockquote>
<p>I presume you want to say "in the osmo-gsm-tester support for osmo-bts-trx" ?</p>
</blockquote>
<p>yes of course :-) I was writing that having osmo-gsm-tester context in mind.</p>
<blockquote>
<p>The normal method used so far AFAIK is to run two soft-TRXs within one<br />osmo-trx instance. This will create two ARFCN carriers inside the<br />spectrum of the USRP. That's what the "-c 2" option of osmo-trx would<br />do. This is similar to osmo-bts-lc15 or osmo-bts-octphy where we run<br />two phy_instances in one phy_link.</p>
<p>I'm not sure if the "run one phy_instance in each phy_link of two<br />separate osmo-trx instances" would work without significant changes to<br />osmo-trx, whcih I believe is out of scope here.</p>
</blockquote>
<p>Ah thanks for the clarification, I wrote everything from what I remembered at the time off the top of my head. Then supporting it (several phy instances per phy device) should be easier than expected then. Let's target for that one then. However, I'm not sure if we actually have any osmo-trx devices that works with more than 1 trx. AFAIK sysmocell5000 doesn't support ore than 1, and same goes for B200. The LimeSDR (not the mini one) theoretically could support 2 TRX.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68342017-12-15T18:29:09Zlaforge
<ul></ul><p>On Fri, Dec 15, 2017 at 02:46:01PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>However, I'm not sure if we actually have any osmo-trx devices that<br />works with more than 1 trx. AFAIK sysmocell5000 doesn't support ore<br />than 1, and same goes for B200. The LimeSDR (not the mini one)<br />theoretically could support 2 TRX.</p>
</blockquote>
<p>Correct for sysmoCell 5000. But for B200 and Lime:</p>
<p>I'm sometimes surprised where you get come up with those<br />assumptions/presumptions ;) This is not a rhethoric question! I'm<br />really curious, where you found that information, because it's wrong.<br />So let's try to find the source of this and fix it to avoid other people<br />drawing the same conclusions.</p>
<p>osmo-trx has had two-TRX suport on USRPs since.. I think forever. Even<br />OpenBTS Transceiver from which it is inherited had the feature, AFAIR. At<br />least the "-c" option was already present in the first commit in 2011,<br />so I assume it was already working back then.</p>
<p>Also, why would LimeSDR and LimeSDR mini be different? It's the same<br />transceiver chip, isn't it?</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68372017-12-15T22:01:05Zpespin
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>Correct for sysmoCell 5000. But for B200 and Lime:</p>
<p>I'm sometimes surprised where you get come up with those<br />assumptions/presumptions ;) This is not a rhethoric question! I'm<br />really curious, where you found that information, because it's wrong.<br />So let's try to find the source of this and fix it to avoid other people<br />drawing the same conclusions.</p>
</blockquote>
<p>It's more like the opposite: I don't remember reading any information in any place stating that 2 TRX are supported, and I don't remember neither hearing about somebody operating it with more than 1 TRX, so my assumption is that it's most probably not supported, but I see I assumed wrong in this case :-)</p>
<blockquote>
<p>Also, why would LimeSDR and LimeSDR mini be different? It's the same<br />transceiver chip, isn't it?</p>
</blockquote>
<p>I recall seeing it when doing a quick look at <a class="external" href="https://www.crowdsupply.com/lime-micro/limesdr-mini">https://www.crowdsupply.com/lime-micro/limesdr-mini</a> (search for "Comparison Table"). It states LimeSDR has 2 TX and 2 RX channels while for LimeSDR Mini it states 1+1. Did I understand that information incorrectly? <br />Actually, now that I look closer at it, it seems to be that Ettus B200 supports only 1 while Ettus B210 supports 2.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=68382017-12-16T11:10:13Zlaforge
<ul></ul><p>On Fri, Dec 15, 2017 at 10:01:05PM +0000, pespin [REDMINE] wrote:</p>
<blockquote><blockquote>
<p>Also, why would LimeSDR and LimeSDR mini be different? It's the same<br />transceiver chip, isn't it?</p>
</blockquote>
<p>I recall seeing it when doing a quick look at <a class="external" href="https://www.crowdsupply.com/lime-micro/limesdr-mini">https://www.crowdsupply.com/lime-micro/limesdr-mini</a> (search for "Comparison Table"). It states LimeSDR has 2 TX and 2 RX channels while for LimeSDR Mini it states 1+1. Did I understand that information incorrectly? <br />Actually, now that I look closer at it, it seems to be that Ettus B200 supports only 1 while Ettus B210 supports 2.</p>
</blockquote>
<p>The count of physical connectors on a given board has absolutely no relationship to the question<br />of how many individual GSM RF carriers you are putting on it.</p>
<p>Let's say you have a 5 MHz wide transmit/receive band at the ADC/DAC of<br />your SDR. Within those 5 MHz you can put a number of the only 270kHz<br />wide GSM carriers. In theory up to 9 non-overlapping ARFCNs (i.e. with<br />one ARFCN space in between), but that's unrealistic/impractical for a<br />large number of other factors, last but not least computational<br />complexity.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=109392018-08-23T16:13:27Zpespin
<ul></ul><p>Side note: See <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/10583/">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/10583/</a> as an example on how to set up osmo-gsm-tester config to use more than 1 TRX.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=113892018-09-17T13:55:44Zlaforge
<ul></ul><p>what's that status here? aside from the "side note" 25 days ago, there hasn't been any update for 9 months?</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=113912018-09-17T14:10:38Zpespin
<ul></ul><p>Status is: We have a reasonably good way to define and configure several TRXs now in osmo-gsm-tester, and it has been tested with nanobts. What is lacking is implementing and testing the related bits in ./src/osmo_gsm_tester/bts_osmo.py to generate the osmo-bts-trx .cfg file with those TRX, and pass the related config to osmo-bsc. I guess we also need to configure osmo-trx launched accordingly (1 channel per TRX?).</p>
<p>I can work on that soon, shall I increase priority?</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=113922018-09-17T14:30:12Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-2 priority-default" href="/issues/3560">Bug #3560</a>: nanoBTS multiTRX tests in osmo-gsm-tester Prod setup failing</i> added</li></ul> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=113992018-09-17T18:34:27Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>60</i></li></ul><p>Support added in:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11000">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11000</a> osmo-bts-trx: Add multiTRX support<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11001">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11001</a> osmo-trx: Add multi_arfcn support</p>
<p>However, we cannot enable it yet for B200 because that on can only do multiTRX through multi_arfcn and the APU machine we use to run osmo-gsm-tester cannot cope with CPU requirements added by multi_arfcn overhead. osmo-bts-trx and osmo-trx will fail after a few seconds due to timers failing to do stuff on time.</p>
<p><a class="user active" href="https://osmocom.org/users/72">roh</a> , most probably we'll need to upgrade it to an APU2. Maybe we should do some manual tests with one to make sure an APU2 is enough beforehand too.</p>
<p>Tomorrow I'll give a try to sysmocell5000 to see if it supports configuration of 2 TRX.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=114342018-09-18T15:39:01Zpespin
<ul><li><strong>Assignee</strong> changed from <i>pespin</i> to <i>roh</i></li></ul><p>Assigning to <a class="user active" href="https://osmocom.org/users/72">roh</a> for him to set up a core network with an ettus B200 in an APU2 with osmo-trx running with multi-arfcn enabled to see if the APU2 is able to keep up with the CPU load.</p>
<p>Sample osmo-trx.cfg (as used by osmo-gsm-tester [1]) with multi-arfcn enabled: (you probably need to run as root due to rt-prio 18)<br /><pre>
!
! OsmoTRX example configuration
!
log stderr
logging filter all 1
logging color 1
logging print category 1
logging timestamp 1
logging print file basename
logging print extended-timestamp 1
logging level all info
!
line vty
bind 127.0.0.1
ctrl
bind 127.0.0.1
trx
bind-ip 127.0.0.1
remote-ip 127.0.0.1
base-port 5700
egprs disable
multi-arfcn enable
tx-sps 4
rx-sps 4
clock-ref internal
rt-prio 18
chan 0
chan 1
</pre></p>
<p>And osmo-bts-trx [2]:<br /><pre>
! Configuration rendered by osmo-gsm-tester
log stderr
logging color 1
logging print extended-timestamp 1
logging print category 1
logging level abis debug
logging level oml debug
logging level pag debug
logging level rll debug
logging level rr debug
logging level rsl debug
logging level l1c info
logging level l1p error
logging level trx info
! Level required by ready_for_pcu(): pcu info
logging level pcu info
!
line vty
bind 127.0.0.1
ctrl
bind 127.0.0.1
!
phy 0
osmotrx ip local 127.0.0.1
osmotrx ip remote 127.0.0.1
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
instance 1
osmotrx rx-gain 25
osmotrx tx-attenuation oml
bts 0
band GSM-1800
ipa unit-id 6 0
oml remote-ip 127.0.0.1
pcu-socket /tmp/foo
gsmtap-sapi bcch
gsmtap-sapi ccch
gsmtap-sapi rach
gsmtap-sapi agch
gsmtap-sapi pch
gsmtap-sapi sdcch
gsmtap-sapi tch/f
gsmtap-sapi tch/h
gsmtap-sapi pacch
gsmtap-sapi pdtch
gsmtap-sapi ptcch
gsmtap-sapi cbch
gsmtap-sapi sacch
trx 0
phy 0 instance 0
trx 1
phy 0 instance 1
</pre></p>
<p>In osmo-bsc, you need to set the arfcn for each TRX with a difference of 4. In osmo-gsm-tester case we use 868 and 872.</p>
<p>[1] <a class="external" href="https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-trx.cfg.tmpl">https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-trx.cfg.tmpl</a><br />[2] <a class="external" href="https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-bts-trx.cfg.tmpl">https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-bts-trx.cfg.tmpl</a></p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=114622018-09-19T11:54:14Zroh
<ul><li><strong>File</strong> <a href="/attachments/3359">usrp_multi_trx_2.gif</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3359/usrp_multi_trx_2.gif">usrp_multi_trx_2.gif</a> added</li><li><strong>File</strong> <a href="/attachments/3360">usrp_multi_trx_1.gif</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3360/usrp_multi_trx_1.gif">usrp_multi_trx_1.gif</a> added</li><li><strong>Assignee</strong> changed from <i>roh</i> to <i>pespin</i></li></ul><p>i did some tests now and compared multi-arfcn on apu2 to only one arfcn.</p>
<p>one arfcn: one core at ~70% load. system working nicely.</p>
<p>multi-arfcn: one core at 100%, one at 70%, one at 30 and one at 25. the osmo-trx-uhd process shows 250-260% - lots of skipping buffers, system overloaded.</p>
<p>----<br />Wed Sep 19 13:31:11 2018 DDEV <0001> UHDDevice.cpp:857 [tid=140404717168384] An internal receive buffer has filled at 307.432 sec.<br />Wed Sep 19 13:31:11 2018 DDEV <0001> UHDDevice.cpp:1481 [tid=140404717168384] Skipping buffer data: timestamp=983858669 time_end=983783547<br />Wed Sep 19 13:31:11 2018 DMAIN <0000> Transceiver.cpp:1037 [tid=140404717168384] ClockInterface: sending IND CLOCK 1253646<br />----</p>
<p>also the osmo-bts-trx process keeps dying:<br /><0007> l1sap.c:463 1285625/969/03/17/41 Invalid condition detected: Frame difference is 1285625-1285559=66 > 1!</p>
<hr />
<p>i also checked the load per thread:<br />single arfcn:<br />4 threads, all below 25% cpu</p>
<p>multi arfcn:<br />6? threads, one 100%, one 80% 2x 25% and 2x 15%</p>
<p>maybe the load could be even more threaded, but i doubt that this will be enough to get this working with an apu2.</p>
<p>i guess we'll need some i3 or i5 to do this kind of math - if it cannot be optimized a bunch more.</p>
<p>also the signal slope of the 2nd trx looks quite bad, but i am not sure if that changes with enough cpu. also the bts was crashing so fast it was difficult to capture.</p>
<p>note: osmo-bts-trx needs the parameter -t 2 to start</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=114722018-09-19T14:10:08Zlaforge
<ul></ul><p>Ok, I've ordered a supermicro 1U server with front-io (connectors all to front)<br />in the following configuration:</p>
<p>- CPU: Intel XEON D-2123IT / 4C/8T - 2,20GHz / 8MB / 60W<br />- Motherboard: Supermicro X11SDV-4C-TLN2F / 2x10Gbit RJ-45 / 1x NVMe / 4 DIMM / IPMI<br />- Arbeitsspeicher: 8GB / 1x8GB / ECC registered DDR4-2400/2666 / RDIMM<br />- 1. Festplatte: SSD SATA 6Gb/s - 250 GB - 150 TBW - Samsung Consumer 860 Evo MZ-76E250B</p>
<p>The CPU should be slightly faster (for single and multi thread case) than the<br />i7-6500U that I have in my rather high-end Thinkpad x260, so I'm confident we<br />should be safe there. Adding more cores didn't really seem to make sense for<br />such a special-purpose system.</p>
<p>The enclosure is only 25cm deep, so it fits nicely into our LTHW rack.</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=118472018-10-02T14:28:20Zpespin
<ul><li><strong>File</strong> <a href="/attachments/3380">trial-155-run.tgz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3380/trial-155-run.tgz">trial-155-run.tgz</a> added</li><li><strong>% Done</strong> changed from <i>60</i> to <i>70</i></li></ul><p>I added a few commits to osmo-gsm-tester to be able to run osmo-trx in a remote machine through ssh (took more than expected due to issues with killing process after ssh session is stopped).</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11191/">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11191/</a> osmotrx: Allow running osmo-trx from remote host<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11192/">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11192/</a> osmotrx: Make sure remote process stops after ssh session is closed<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11196">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11196</a> resources.conf.prod: Use specific remote machine to run osmo-trx<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11197">https://gerrit.osmocom.org/#/c/osmo-gsm-tester/+/11197</a> osmo-trx: Enable multi_arfcn for B200 and only in multiTRX setup</p>
<p>I then configured the new machine and run some tests to check how it behaves. With 1 TRX is runs nicely and tests pass. However, when running with multi-arfcn enabled and 2 TRX, the MS is able to see the network but registering fails with status=denied.<br />This is how I'm running it (with osmo-gsm-tester branch pespin/remote-trx): "-s ussd:trx-b200+mod-bts0-numtrx2+mod-bts0-chanallocdescend" <br />Looking more in detail at traces (see attached run.tgz), GSMTAP shows all the usual System Information downlink messages, and I can even see an uplink RACH request (gsmtap.uplink == 1), but nothing else.</p>
<p>In logs I see lots of messages with an always increasing by 1 value (starting from 0:4):<br /><pre>
...
[0;m20181002160541813 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4958
[0;m20181002160541866 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4959
[0;m20181002160541976 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4960
[0;m20181002160542026 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4961
[0;m20181002160542066 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1037 [tid=140021839468288] ClockInterface: sending IND CLOCK 386945
[0;m20181002160542075 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4962
[0;m20181002160542126 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4963
[0;m20181002160542180 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4964
[0;m20181002160542226 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4965
[0;m20181002160542279 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4966
[0;m20181002160542334 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4967
[0;m20181002160542382 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4968
[0;m20181002160542436 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4969
[0;m20181002160542484 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4970
[0;m20181002160542539 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4971
[0;m20181002160542591 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4972
[0;m20181002160542655 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4973
[0;m20181002160542707 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4974
[0;m20181002160542822 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4975
[0;m20181002160542877 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4976
[0;m20181002160542935 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4977
[0;m20181002160542986 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4978
[0;m20181002160543053 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1037 [tid=140021839468288] ClockInterface: sending IND CLOCK 387162
[0;m20181002160543083 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4979
[0;m20181002160543140 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4980
[0;m20181002160543187 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4981
[0;m20181002160543239 [1;32mDMAIN[0;m <0000> Transceiver.cpp:1004 [tid=140021839501056] new latency: 0:4982
</pre></p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=118482018-10-02T14:33:00Zpespin
<ul></ul><p>We are entering this condition every time (Transceiver.cpp:1004):<br /><pre>
// if underrun, then we're not providing bursts to radio/USRP fast
// enough. Need to increase latency by one GSM frame.
if (mRadioInterface->getWindowType() == RadioDevice::TX_WINDOW_USRP1) {
if (mRadioInterface->isUnderrun()) {
// only update latency at the defined frame interval
if (radioClock->get() > mLatencyUpdateTime + GSM::Time(USB_LATENCY_INTRVL)) {
mTransmitLatency = mTransmitLatency + GSM::Time(1,0);
LOG(INFO) << "new latency: " << mTransmitLatency;
mLatencyUpdateTime = radioClock->get();
}
}
...
</pre></p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=119762018-10-03T14:01:35Zpespin
<ul></ul><p>From BTS point of view, one RACH request is received but it's discarded due to bad quality:<br /><pre>
20181002160512715 DL1C <0006> l1sap.c:1234 380582/287/20/20/10 Ignoring RACH request: BER10k(1944) > BER10k_MAX(1707)
</pre></p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=124892018-11-01T16:57:36Zpespin
<ul></ul><p>I tested B200 with 2 chan and multi-arfcn on my local setup, and it's working fine there (see <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: neels/inter_bsc_ho branch for osmo-bsc 2TRX configured but OSMO-BSC only uses the first TRX confi... (Resolved)" href="https://osmocom.org/issues/3475">#3475</a>).</p> OsmoGSMTester - Feature #2760: osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrxhttps://osmocom.org/issues/2760?journal_id=160432019-09-20T10:29:08Zpespin
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>70</i> to <i>100</i></li></ul><p>osmo-gsm-tester already supports running multi-trx and multi-arfcn. b200 multi-arfcn osmo-trx issues are being tracked currently in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: multi-arfcn not working properly (Resolved)" href="https://osmocom.org/issues/4207">#4207</a>, so let's close this ticket.</p>