<div dir="auto">Hi Neels,<div dir="auto"><br></div><div dir="auto">Are you running osmo-trx in a single TRX or dual-TRX configuration?</div><div dir="auto"><br></div><div dir="auto">Do you have a CPU usage information from the system?</div><div dir="auto"><br></div><div dir="auto">Could you try disabling all timeslots but the ones take needed? It won't completely disable them with the current code, but IIRC it will somewhat help with the CPU load which I think is the real issue here.<br><br><div data-smartmail="gmail_signature" dir="auto">Please excuse typos. Written with a touchscreen keyboard.<br><br>--<br>Regards,<br>Alexander Chemeris<br>CTO/Founder Fairwaves, Inc.<br><a href="https://fairwaves.co">https://fairwaves.co</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 25, 2017 22:23, "Neels Hofmeyr" <<a href="mailto:nhofmeyr@sysmocom.de">nhofmeyr@sysmocom.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 23, 2017 at 11:19:10AM +0200, Harald Welte wrote:<br>
> Hi Neels,<br>
><br>
> On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote:<br>
> > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester.<br>
><br>
> I'm sorry, but I have to ask for more specifics:<br>
> What exactly is a 'massive stability problem'?  How does it manifest<br>
<br>
To quantify: between 30 and 40% of all osmo-gsm-tester runs fail because of:<br>
<br>
20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1!<br>
20170625121036320 DL1C <0006> scheduler_trx.c:1527 GSM clock skew: old fn=2289942, new fn=2290004<br>
20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1!<br>
<br>
Detailed logs in<br>
<a href="http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/940/artifact/trial-940-run.tgz" rel="noreferrer" target="_blank">http://jenkins.osmocom.org/<wbr>jenkins/view/osmo-gsm-tester/<wbr>job/osmo-gsm-tester_run/940/<wbr>artifact/trial-940-run.tgz</a><br>
in /run.2017-06-25_12-05-43/sms:<wbr>trx/<a href="http://mo_mt_sms.py/osmo-bts-trx/osmo-bts-trx/stderr" rel="noreferrer" target="_blank">mo_mt_sms.py/osmo-bts-trx/<wbr>osmo-bts-trx/stderr</a><br>
<br>
Related osmo-trx output is in the same tgz at<br>
in /run.2017-06-25_12-05-43/sms:<wbr>trx/<a href="http://mo_mt_sms.py/osmo-bts-trx/osmo-trx/stderr" rel="noreferrer" target="_blank">mo_mt_sms.py/osmo-bts-trx/<wbr>osmo-trx/stderr</a><br>
<br>
(Number crunching: if 30% of the test runs fail, where each run contains two<br>
osmo-bts-trx tests, it means that roughly 15% of osmo-bts-trx tests fail.)<br>
<br>
(The reason why I say "massive": it's really annoying to have this rate of<br>
sporadic failure. Instead of investigating upon first failure, we will only<br>
notice a regression when runs fail consistently, i.e. when there are no<br>
successful runs for, say, 5 or more runs. We don't take action immediately, yet<br>
we have to be careful to not be too late and loose jenkins run logs of the last<br>
successful run. The first failing runs in a series can well be just trx<br>
failures, so it needs more effort to find out which run introduced an actual<br>
regression.)<br>
<br>
> > I have run a tcpdump on the ntp port for the past days, and nothing is doing<br>
> > ntp besides the actual ntp service.<br>
><br>
> And that service was presumably disabled (before your test described in<br>
> the next paragraph)?<br>
<br>
Yes, started the tcpdump filtering on the ntp port, saw ntp packets (to verify<br>
that it works), disabled the ntp service, saw that packets cease, restarted the<br>
tcpdump in a tmux, forgot about it for a couple of days, then came back to the<br>
tmux and saw that the tcpdump was completely empty. Then again I started the<br>
ntp service, immediately saw ntp packets in the tcpdump and the osmo-bts-trx<br>
test run failed promptly.<br>
<br>
<br>
Let me mention that I see myself as "the messenger", relaying the results I see<br>
on the tester setup; I will pursue a solution in a limited fashion, to not<br>
neglect other tasks.<br>
<br>
I can of course test things in case anyone has more ideas.<br>
<br>
Tom mentioned the idea of running osmo-bts-trx on a different machine from<br>
osmo-trx -- that is certainly possible in a manual test, but I guess not really<br>
an option for the regular tests. It would be a lot of manual supervision to<br>
perform a series of tests, like 20 or more, to find out the success rate; or a<br>
code and jenkins config change to run the osmo-bts-trx binary on a different<br>
build slave, not trivial. It would be much preferred to stay on a single host<br>
computer...<br>
<br>
~N<br>
</blockquote></div></div>