11 Jan
2019
11 Jan
'19
2:35 p.m.
Just a short update:
Orange Pi Zero (armhf) + Ettus B100 ARFCN 871 osmo-trx-uhd_0.4.0.124
unstable after 5-120 minutes.
Supermicro I386 + Limesdr mini ARFCN 881 osmo-trx-lms_0.4.0_i386 (built
from latest source ) relatively stable.
Incoming and outgoing calls OK. PSTN access OK. Sometimes fails with
"communication error" as displayed on Nokia,
main suspicion is failed trx-uhd ( without handover) will investigate
further. Not sure which BTS it was on.
As for LimeSDR mini support, best so far, has run overnight.
Gullik
11 Jan
11 Jan
2:58 p.m.
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'?
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.
Incoming and outgoing calls OK. PSTN access OK.
Sometimes fails
with "communication error" as displayed on Nokia,
Please attach the logs and PCAP traces.
With best regards,
Vadim Yanitskiy.
4:18 p.m.
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:
Yes, this is clear to me, and I
will verify compile switches for the Arm
cpu.
I will try to catch relevant info, but it requires
"babysitting", to
catch, however I can run gdb of course...
Hi,
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.
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'? 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. Incoming and
outgoing calls OK. PSTN access OK. Sometimes fails
with "communication error" as displayed on Nokia,
Please attach the logs
and PCAP traces.
With best regards,
Vadim Yanitskiy.
Thanks for your comments,
Regards,
Gullik
4:37 p.m.
Hmm,
Features : half thumb fastmult vfp edsp neon vfpv3
tls vfpv4 idiva
idivt vfpd32 lpae evtstrm
feel free to (re)configure:
./configure --with-sse=no --with-neon=yes --with-neon-vfpv4=yes
and recompile.
Also, I recommend to play with 'rt-prio' VTY option.
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.
Hmm, I've never seen anything like that.
With best regards,
Vadim Yanitskiy.
2379
days inactive
2379
days old
3 comments
2 participants
participants (2)
-
Gullik Webjorn -
Vadim Yanitskiy