https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-03-02T09:30:55ZOpen Source Mobile CommunicationsOsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=79972018-03-02T09:30:55Zlaforge
<ul></ul><pre>
Expected (924 .. 978) pagings but have 900
</pre>
<p>So somehow on the jenkins less paging messages make it compared to my local setup. interesting.</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=88892018-04-15T15:19:51Zlaforge
<ul></ul><p>on the jenkins build slave:<br /><pre>
09:30:00.302175 mtc BTS_Tests.ttcn:1569 num_paging_sent=1359 rcvd_msgs=228 rcvd_ids=900
09:30:00.302235 mtc BTS_Tests.ttcn:1660 setverdict(fail): none -> fail reason: "Expected (924 .. 978) pagings but have 900", new component reason: "Expected (924 .. 978) pagings but have 900"
</pre></p>
<p>on my laptop:<br /><pre>
14:20:13.136162 mtc BTS_Tests.ttcn:1569 num_paging_sent=1359 rcvd_msgs=244 rcvd_ids=964
</pre></p>
<p>so for some reason, on my laptop 244-228=16 more messages have been received, each containing 4 identities, resulting in a difference of 64 paged IDs. But why?</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=88912018-04-15T19:39:02Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/7811">https://gerrit.osmocom.org/7811</a></p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=115942018-09-25T15:30:50Zpespin
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>New</i></li></ul><p>This test fails with osmo-bts-trx+osmo-trx+motorola CXX but in the other direction, that is, it's now expecting less messages than the amount arriving:</p>
<pre>
MTC@6a1670a53352: Setting RSL_SYSTEM_INFO_4 (4): '31061C62F224002A4740E50400'O
MTC@6a1670a53352: pch_blocks_per_sec=67.973856 interval=0.014712
...
MTC@6a1670a53352: num_paging_sent=1359 rcvd_msgs=318 rcvd_ids=1258
MTC@6a1670a53352: Test case TC_paging_tmsi_200percent finished. Verdict: fail reason: Expected (896 .. 978) pagings but have 1258
</pre>
<p>So it seems <a class="external" href="https://gerrit.osmocom.org/7811">https://gerrit.osmocom.org/7811</a> is not the proper definitive fix for this test.</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=115952018-09-25T15:31:30Zpespin
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>pespin</i></li></ul> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=115962018-09-25T15:31:43Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-3 priority-high3" href="/issues/3155">Feature #3155</a>: execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW setup</i> added</li></ul> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=116262018-09-26T13:51:28Zpespin
<ul></ul><p>This is what we get when running docker non-HW test:<br /><pre>
10:41:24.054141 mtc BTS_Tests.ttcn:1761 num_paging_sent=1359 rcvd_msgs=236 rcvd_ids=935
</pre></p>
<p>Ratio of received ids per message is similar (1272/322=3.95 vs 935/236=3.96), but in the non-HW one a lot less messages are received in the MS (318 vs 236).</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=116282018-09-26T14:13:42Zlaforge
<ul></ul><p>On Wed, Sep 26, 2018 at 01:51:28PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>Ratio of received ids per message is similar (1272/322=3.95 vs 935/236=3.96), but in the non-HW one a lot less messages are received in the MS (318 vs 236).</p>
</blockquote>
<p>this is odd. After all, the bandwidth of the downlink CCCH (and the PCH within<br />that) is fixed. It is impacted by BS_AG_BLKS_RES as well as the channel configuration<br />(combined vs. non-combined BCCH/CCCH). But neither of those should change between<br />executing with trxcon+fake_trx or with real hardware.</p>
<p>The number of PCH slots determines the number of PCH messages that can be sent,<br />and the number of PCH messages determines the number of paging identities,<br />depending on whether PAGING TYPE 1/2/3 is generated based on the identities.</p>
<p>So in order to debug this, I think I would start to count the number of PCH<br />messages sent on the BTS side vs. those received by the MS. This can be done<br />completely outside of the osmo-gsm-tester setup and in any virtual or real setup.</p>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> can help you with computing the theoritcal amount of PCH blocks on a<br />combined and a non-combined CCCH, which should give you some context as to what<br />we actually expect.</p>
Make sure to distinguish between
<ul>
<li>the number of RSL PAGING messages on Abis,</li>
<li>the number of paging blocks sent on the PCH</li>
<li>the number of identities contained in above blocks</li>
</ul>
<p>Those figures are all separate, and there are processes within OsmoBTS which<br />aggregate RSL PAGING commands into PCH blocks with multiple identities. And<br />it's that paging aggregation process that we actually want to test under overload<br />conditions, i.e. when a sustained flow of RSL PAGING messages exceeds twice<br />the capacity of the PCH capacity, even if the aggregation works ideal.</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=116292018-09-26T15:17:23Zpespin
<ul><li><strong>File</strong> <a href="/attachments/3370">shot-2018-09-26_17-11-51.jpg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3370/shot-2018-09-26_17-11-51.jpg">shot-2018-09-26_17-11-51.jpg</a> added</li></ul><p>Comparing time span of HW and trxcon setups (time from 1st packet to last one):</p>
GSMTAP Paging Info:
<ul>
<li>HW: 37 seconds</li>
<li>trxcon: 27 seconds</li>
</ul>
RSL Paging Command:
<ul>
<li>HW: 32 seconds</li>
<li>trxcon: 20 seconds</li>
</ul>
<p>So the issue is clearly with TTCN3 in the HW setup not sending RSL paging commands in the specified time (20 seconds). As a result, BTS receives paging at a slower peace and hence has time to forward more IDs to the MS.</p>
<p>Following comparision of graphs from pcap trace in both setups shows the issue (HW setup run sends less paging commands per second). This is probably due to the HW setup running osmo-trx on an APU machine, which eats most of the CPU and thus TTCN3 test is not scheduled on time. TTCN3 test always sends a paging command, then waits for a fixed interval, instad of accunting for scheduling delays.</p>
<p>So we need to fix the test to account for scheduling delay, then it should be fine.</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=116312018-09-26T18:37:50Zpespin
<ul></ul><p>After my changes to account for scheduling delays, variation of packet frequency and time span over whole test look a lot better, and more similar in both machines (my high end laptop running trxcon setup and the low end APU running osmo-trx with HW setup).</p>
<p>However, since now the test really follows the 20 seconds, throughput of received paging IDs has slowed down a bit, because previous implementation always drifted a bit (like 2 secs) even in high end setups, so osmo-bts had more time to manage the pagings.</p>
<p>For imsi_200: "Expected (543 .. 577) pagings but have 541" on trxcon, "Expected (543 .. 577) pagings but have 536" on HW setup.<br />For tmsi_200: "Expected (896 .. 978) pagings but have 883" on trxcon, "(896 .. 978) pagings but have 874" on HW setup (and sometimes it even passes with current thresholds).</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=116322018-09-26T18:44:30Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>Should be fixed by:<br /> <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11103">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11103</a> bts: Account for elapsed time in paging timer</p>
<p>I tested it several time in my PC (docker, trxcon) as well as on real HW with osmo-trx.</p> OsmoBTS - Bug #3025: BTS_Tests.TC_paging_tmsi_200percent failshttps://osmocom.org/issues/3025?journal_id=119512018-10-03T10:32:30Zpespin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>Merged, closing.</p>