<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Closing this thread.<br>
<br>
<div class="moz-cite-prefix">On 2019-02-05 19:03, Harald Welte
wrote:<br>
</div>
<blockquote type="cite" cite="mid:20190205180328.GR24515@nataraja">
<pre class="moz-quote-pre" wrap="">It may be some particularly nasty driver on your platform. It may be
thermal throttling due to insufficient cooling of the CPU, ...
</pre>
</blockquote>
<br>
<blockquote type="cite" cite="mid:20190205180328.GR24515@nataraja">
<pre class="moz-quote-pre" wrap="">Regards,
Harald
</pre>
</blockquote>
Well, now the puzzle is solved for this platform. The Orange Pi Zero
in conjunction<br>
with Armbian has a cpu temperature governor. Reducing the max cpu
speed down<br>
to 816 Mhz, the cpu utilization goes up, to 200% ( out of 400 ).
This lowers the <br>
temperature by c:a 10 C. When the cpu temperature exceeds some
value, the <br>
governor downshifts clock, and execution of Transceiver is
disturbed, and I am now convinced<br>
this is the cause of the problem with this platform.<br>
<br>
It does not make complete sense from a mathematical point of view,
but I do not have the<br>
insight into the inner workings of the "governor". Reducing the
maximum rate and increasing<br>
the minimum rate I have reached stability over night. A heat sink
has also been added to the cpu.<br>
Using armbianmonitor -m, the critical temperature seems to be c:a 65
C.<br>
<br>
MY earlier observations is that the bug was hit "randomly" ,
sometimes after 30 seconds, sometimes<br>
not for several hours. This randomness is most probably due to room
temperature, drafts from entering<br>
or exiting the lab and air flow around the system.<br>
<br>
With regards to osmo-bts software, the changes I propose are:<br>
<br>
1) ALARM LOG in <br>
<br>
void LMSDevice::update_stream_stats(size_t chan, bool * underrun,
bool * overrun)<br>
{<br>
lms_stream_status_t status;<br>
if (LMS_GetStreamStatus(&m_lms_stream_rx[chan], &status)
== 0) {<br>
if (status.underrun > m_last_rx_underruns[chan])<br>
*underrun = true;<br>
m_last_rx_underruns[chan] = status.underrun;<br>
<br>
if (status.overrun > m_last_rx_overruns[chan])<br>
*overrun = true;<br>
m_last_rx_overruns[chan] = status.overrun;<br>
<b>// if the radio drops packets it is good information to know it,
this is a FATAL condition with regards to stable operation of
Transceiver this + 4 more lines</b><b><br>
</b><b> if (status.droppedPackets != 0) {</b><b><br>
</b><b> dropped = dropped + status.droppedPackets;</b><b><br>
</b><b> LOGC(DDEV, ALERT) << "Dropped " <<
status.droppedPackets << " Total dropped " << dropped;</b><b><br>
</b><b> }</b><br>
}<br>
}<br>
<br>
2) Possibly causing this condition to either cause Transceiver exit
or controlled restart ( which happens anyway, but many seconds later
)<br>
<br>
Now on to "balancing LimeSDR up/down links"......<br>
<br>
Regards,<br>
<br>
Gullik<br>
<br>
<br>
<br>
<br>
</body>
</html>