Cpuinfo:

root@orangepizero:~# cat /proc/cpuinfo processor    : 0 model name    : ARMv7 Processor rev 5 (v7l) BogoMIPS    : 120.00 Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer    : 0x41 CPU architecture: 7 CPU variant    : 0x0 CPU part    : 0xc07 CPU revision    : 5

there are 4 of these.....so multithreading makes sense.....load 85% / 400% htop looks nice....

On 2019-01-11 20:58, Vadim Yanitskiy wrote:

Hi,

...

Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 osmo-trx-uhd_0.4.0.124 unstable after 5-120 minutes.

Have you tried to compile OsmoTRX with NEON SMID? See both --with-neon and --with-neon-vfpv4 configure options. Before doing that, make sure that your CPU does support them. This can be checked using 'cat /proc/cpuinfo'.

Also, could you please clarify, what do you mean by 'unstable'?

After 5 to 120 minutes (random) the trx goes into this loop behaviour:

Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69514 (underrun 0:2524734 vs 4:2524732) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.01 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.04 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69515 (underrun 7:2524745 vs 0:2524744) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.07 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.09 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.12 sec. Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:1005 [tid=3008443472] new latency: 7:69516 (underrun 4:2524757 vs 7:2524755) Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. Fri Jan 11 22:00:15 2019 DDEV <0002> UHDDevice.cpp:1319 [tid=2998391888] Packet loss between host and device at 6618.15 sec. ^Csignal 2 received shutting down    ---THIS is myself stopping the transceiver.

Fri Jan 11 22:00:15 2019 DMAIN <0000> osmo-trx.cpp:435 [tid=3070163440] Shutting down transceiver... Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:307 [tid=3070163440] Stopping the transceiver Fri Jan 11 22:00:15 2019 DMAIN <0000> Transceiver.cpp:320 [tid=3070163440] Stopping the device Fri Jan 11 22:00:16 2019 DMAIN <0000> Transceiver.cpp:333 [tid=3070163440] Transceiver stopped

Restarting it goes back to proper operation, for x minutes, then it hits this situation. I have seen it recover back to normal once or twice,

but often it loops forever as above. Since stopping / starting it corrects the problem, it seems the internal fail-safe mechanizm does not

work properly. Some times it exits, i.e. stops by itself. I will get a fingerprint of that... Note I am running the "same build" trx on both systems

however I could swap the SDR's to find out if the problem stays with the platform or the sdr device and its particular driver code.

...

Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 (built from latest source ) relatively stable.

Most likely, because the CPU does support SSE instructions. Please note that they aren't supported on ARM.

Yes, this is clear to me, and I will verify compile switches for the Arm cpu.

...

Incoming and outgoing calls OK. PSTN access OK. Sometimes fails with "communication error" as displayed on Nokia,

Please attach the logs and PCAP traces.

I will try to catch relevant info, but it requires "babysitting", to catch, however I can run gdb of course...

With best regards, Vadim Yanitskiy.

Thanks for your comments,

Regards,

Gullik