https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-06-29T13:05:51ZOpen Source Mobile CommunicationsOsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43832017-06-29T13:05:51Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43852017-06-29T13:07:51Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-1 priority-lowest closed" href="/issues/2325">Bug #2325</a>: sporadic shutdown of osmo-bts-trx in osmo-gsm-tester runs (no clock from trx)</i> added</li></ul> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43862017-06-29T13:22:15Zlaforge
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>20</i></li></ul><p>Using a quick exerimental patch to enable SCHED_RR, I can get osmo-trx and osmo-bts-trx to run on a system with load > 100, created by the following stress-ng command line:<br /><code>stress-ng --vm 10 --hdd 10 --cpu 10 --open 10 --sem 10 --sock 10 --float 10 --io 10 --timer 10</code></p>
<p>With my SCHED_RR patch, osmo-trx and osmo-bts-trx are running perfectly fine, despite the high system load. Prior to the SCHED_RR patch, osmo-trx basically immediately throws errors like<br /><pre>
NOTICE 140480399431424 15:19:43.5 Transceiver.cpp:381:pushRadioVector: dumping STALE burst in TRX->USRP interface
</pre></p>
<p>and osmo-bts-trx shows high clock deviation like<br /><pre>
<0006> scheduler_trx.c:1704 We were 16 FN faster than TRX, compensating
</pre></p>
<p>so definitely, using SCHED_RR significantly improves performance under high system load.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43872017-06-29T13:23:34Zlaforge
<ul><li><strong>File</strong> <a href="/attachments/2696">osmo-trx-sched_rr.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2696/osmo-trx-sched_rr.diff">osmo-trx-sched_rr.diff</a> added</li><li><strong>% Done</strong> changed from <i>20</i> to <i>40</i></li></ul><p>attaching patch for unconditional use of SCHED_RR.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43882017-06-29T13:39:45Zlaforge
<ul><li><strong>% Done</strong> changed from <i>40</i> to <i>80</i></li></ul><p>proper patch now in <a class="external" href="https://gerrit.osmocom.org/#/c/3080/1">https://gerrit.osmocom.org/#/c/3080/1</a></p>
<p>However, I think we should actually make it a default.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43922017-06-30T07:08:56Zttsou
<ul></ul><p>OsmoTRX already uses SCHED_RR by default, however, Harald's positive result confirms a counterintuitive result. Instead of setting individual RT priorities on the primary I/O threads (as below), better results are obtained by calling sched_setscheduler() from main(). The main() thread simply loops on sleep() during operation, which is why priorities were not setup this way before.</p>
<p>The likely reason for the improved behavior is that the libusb event handler, which runs <em>below</em> osmo-trx was not being prioritized before. The scheduling setting in main() prioritizes UHD threads and likely prevents osmo-trx from preempting libusb and UHD which both run in userspace.</p>
<p>I've seen similar improvements in higher bandwidth LTE test cases, but never reached the same conclusion in osmo-trx.</p>
<pre><code class="C syntaxhl"><span class="kt">void</span> <span class="nf">RxLowerLoopAdapter</span><span class="p">(</span><span class="n">Transceiver</span> <span class="o">*</span><span class="n">transceiver</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">transceiver</span><span class="o">-></span><span class="n">setPriority</span><span class="p">(</span><span class="mi">0</span><span class="p">.</span><span class="mi">45</span><span class="p">);</span>
<span class="k">while</span> <span class="p">(</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="n">transceiver</span><span class="o">-></span><span class="n">driveReceiveRadio</span><span class="p">();</span>
<span class="n">pthread_testcancel</span><span class="p">();</span>
<span class="p">}</span>
<span class="k">return</span> <span class="nb">NULL</span><span class="p">;</span>
<span class="p">}</span>
</code></pre> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=43932017-06-30T07:20:10Zttsou
<ul></ul><p>Can you remove or disable the calls to RadioDevice::setPriority() and still maintain the same performance?</p>
<p>The current settings set priorities through the UHD scheduling wrapper, which then enabled SCHED_RR and priorities by calling pthread_setschedparam(). I'm not sure these calls have a significant effect when RT scheduling is already configured by the parent thread.</p>
<p>I also prefer not to have separate scheduling implementations that could potentially conflict.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=59782017-10-29T18:41:18Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=92382018-05-09T10:09:39Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>pespin</i></li></ul> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=126152018-11-19T13:22:36Zmsuraev
<ul></ul><p>On somewhat related note: I've noticed that when I run osmo-trx manually on my system as a user, it fails to set SCHED_RR but running it with <code>systemctl --user</code> it works fine. I've got system.conf and user.conf altered to set proper DefaultLimitRTPRIO.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=156572019-08-21T11:07:23Zpespin
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Feedback</i></li></ul><p>Related patch submitted in<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-trx/+/15258">https://gerrit.osmocom.org/c/osmo-trx/+/15258</a> Drop old setPriority related code</p>
<p>Once merged this ticket can be closed.</p> OsmoTRX - Bug #2344: OsmoTRX is not using SCHED_RRhttps://osmocom.org/issues/2344?journal_id=156922019-08-26T08:57:02Zpespin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>Merged, closing.</p>