GNU-Radio GUI applications freeze

Hello,
I’m running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
and all the USRP graphical (GUI) applications freeze, such as
usrp_oscope.py or usrp_fft.py.

The application, eg. usrp_oscope.py, main window is displayed but only
the signal diagram is visible and changes. All the controls and
buttons are not available. Sporadically the whole window, signal
diagram plus controls, is displayed but it is not possible to interact
with or adjust any control.

I’ve also tried compiling the stable GNU-Radio 3.1.2 version, and even
with GNU-Radio and USRP from the Fedora yum repositories
(3.1.2-2.fc8). I’m experiencing the same behaviour with all them. The
GNU-Radio and USRP command-line tools work fine, so it seems an issue
with wxPython and Fedora.

I’m using the 2.6.25.14-69.fc8 kernel version and wxPython version:

rpm -aq | grep wxPython

wxPython-2.8.7.1-5.fc8
wxPython-devel-2.8.7.1-5.fc8

The computer VGA card is an ATI model:

lspci

00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP
340M] (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP
330M/340M/350M

Has anyone experienced a similar behaviour? Any help or hints to
troubleshoot this issue are appreciated! Thanks!

Raul S.
www.raulsiles.com

On Sat, Sep 06, 2008 at 01:57:31AM +0200, Raul S. wrote:

Hello,
I’m running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
and all the USRP graphical (GUI) applications freeze, such as
usrp_oscope.py or usrp_fft.py.

Raul,

What kind of computer are you running these tests on?

$ cat /proc/cpuinfo

Eric

Hello Eric,
The computer is a laptop with a Pentium 4 CPU and 1GB of RAM (only
350MB are used). When any of the GNU Radio GUI tools is launched, the
associated python process goes up to near 100% CPU usage.

cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Genuine Intel(R) CPU 2.80GHz
stepping : 9
cpu MHz : 1596.000
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts
cid xtpr
bogomips : 3196.91
clflush size : 64

Thanks,

Raul S.
www.raulsiles.com

On Fri, Sep 5, 2008 at 4:57 PM, Raul S. [email protected] wrote:

I’m running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
and all the USRP graphical (GUI) applications freeze, such as
usrp_oscope.py or usrp_fft.py.

At first glance, this seems like a performance issue, but your CPU is
sufficient.

I’m using the 2.6.25.14-69.fc8 kernel version and wxPython version:
wxPython-2.8.7.1-5.fc8

This is the same wxPython version I am using successfully on Ubuntu
8.04, though the kernel is 2.6.24.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

I can reproduce something similar I think on Ubuntu 8.04 using recent
svn sources with the included grc to make an audio signal source and
scope sink, not using any usrp etc.

The scope gui displays the waveform but the mouse cannot get focus on
any buttons.

Then I installed the latest stable release of gnuradio 3.1.3 and the
separate grc 0.7, and everything works correctly as expected.

Hardware here is a iMac

jim@imac:~/Desktop/grc_0.70/src$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel® CPU 1500 @ 2.00GHz
stepping : 8
cpu MHz : 2000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc bts
pni monitor vmx est tm2 xtpr
bogomips : 4004.41
clflush size : 64

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel® CPU 1500 @ 2.00GHz
stepping : 8
cpu MHz : 2000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc bts
pni monitor vmx est tm2 xtpr
bogomips : 3999.98
clflush size : 64

On Mon, 2008-09-08 at 07:24 -0700, Johnathan C. wrote:

I just tried that - it works exactly as you predicted :wink:
thanks
jim

On Mon, Sep 8, 2008 at 1:26 AM, Jim W. [email protected] wrote:

I can reproduce something similar I think on Ubuntu 8.04 using recent
svn sources with the included grc to make an audio signal source and
scope sink, not using any usrp etc.

In this particular case, since there is no rate limiting block, the
source and sink run at the fastest possible rate and consume all the
CPU, resulting in what you are seeing. You can use gr.throttle
between them to eliminate the problem.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

I’m using the 2.6.25.14-69.fc8 kernel version and wxPython version:
wxPython-2.8.7.1-5.fc8

This is the same wxPython version I am using successfully on Ubuntu
8.04, though the kernel is 2.6.24.

I have tested it too using the Fedora 2.6.23.1-42 kernel version with
the same results :frowning:

Are there any specific test I could try to troubleshoot Python,
wxPython, or any other GUI component?
Anyone else running GNU Radio & USRP on Fedora 8 succesfully?

Thanks!

Raul S.
www.raulsiles.com

On Sun, Sep 7, 2008 at 6:30 PM, Johnathan C.

On Tue, Sep 09, 2008 at 01:41:30AM +0200, Raul S. wrote:

wxPython, or any other GUI component?
Anyone else running GNU Radio & USRP on Fedora 8 succesfully?

Thanks!

Raul S.
www.raulsiles.com

Fedora 7, 8, and 9 are known to work fine. I us them.

Eric

As Matt is so fond of pointing, I LOVE to install new toys.

I have F 8,9, Ubuntu 8.04 with F8 and F9 on x86, x86_64, PPC, and
Cell. I have Ubuntu 8.04 on x86, x86_64.

They all do gnuradio.

Bob

Hello again,
After hearing about success cases of GNU Radio and the USRP GUI tools
on Fedora 8 and 9, and after reviewing and retesting the previously
described setup, I’ve reinstalled my whole GNU Radio environment under
Fedora 9 (vs Fedora 8) using the same laptop. Fedora 9 has been fully
updated today. I’m using GNU Radio 3.1.3 but I’m still suffering the
same GUI-based tools freeze issue.

When running “usrp_oscope.py” (or other GUI tools, like
“usrp_wfm_rcv.py”) I get the following warning messages:

usrp_oscope.py -f 2.412G

** (python:2988): WARNING **: IPP request failed with status 1030

** (python:2988): WARNING **: IPP request failed with status 1030
uOuOuOuOuOuOuOuOuOuOuOuOuOuOuOKilled

After some searching, I didn’t find how to remove and solve them,
although they seem to be related with wxPython (and perhaps the issue
I’m suffering). Could anyone confirm this?

I’ve tried to run other (non GNU Radio) wxPython basic examples, such
as “/usr/share/doc/wxPython-2.8.7.1/samples/wxProject/wxProject.py”,
and they work fine.

Some details about the current setup:

  • wxPython versions:

rpm -aq | grep -i wx

wxPython-devel-2.8.7.1-5.fc9.i386
wxBase-2.8.7-2.fc9.i386
wxGTK-gl-2.8.7-2.fc9.i386
wxGTK-devel-2.8.7-2.fc9.i386
wxPython-2.8.7.1-5.fc9.i386
wxGTK-2.8.7-2.fc9.i386

  • CPU:

cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Genuine Intel® CPU 2.80GHz
stepping : 9
cpu MHz : 1596.000
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid
xtpr
bogomips : 3196.88
clflush size : 64
power management:

  • Graphical card and USB bus/ports: (I’m using the USB 2.0 bus/port)

lspci

00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP
340M] (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
00:0b.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0b.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP
330M/340M/350M

  • Kernel version:

uname -a

Linux aereo 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
i686 i686 i386 GNU/Linux

Any suggestion about how to troubleshoot this GUI issue? I’m starting
to think it is related to the hardware I’m using.
Thanks for your help!

Raul S.

Just in case anyone is interested, I’m experiencing the same behavior
(GNU Radio USRP graphical tools freeze, such as usrp_oscope.py) when
running Fedora 9 inside VMware 6.x (it includes USB 2.0 support).

Raul S.

It’s the “scope frame decimation factor”. Try -n100 to start with…
Paul M.

Use the optional parameter in usrp_oscope.py that slows down the data
rate
to where wx can handle it…your screen will then not freeze. I can’t
remember off-hand what it needs to be set to…
Paul M.

Paul, you rock!!!

Changing the decimation factor (-n) to a bigger value (the default
value is 1) works like a charm and solves all my GUI freeze issues,
even within VMware.
I started with “-n 100” (as you suggested) for usrp_oscope.py, but it
is too much and the refresh rate is very slow. Then I tried, 10, 5,
and in my case, it even works great with “-n 2”.

Thanks a lot!!

Raul S.
www.raulsiles.com

Thanks to Jon Jacky then, and all the list members that replied to
this thread trying to help!

Raul S.
www.raulsiles.com

Thanks should go to Jon Jacky, who identified the problem some time ago.
Paul

On Wed, Sep 24, 2008 at 02:18:46AM +0200, Raul S. wrote:

Just in case anyone is interested, I’m experiencing the same behavior
(GNU Radio USRP graphical tools freeze, such as usrp_oscope.py) when
running Fedora 9 inside VMware 6.x (it includes USB 2.0 support).

Raul S.

Raul,

I suspect that your real problem is that your machine is too slow to
run the GUI at the default refresh rate.

Not that we have any such thing as a supported configuration, but if
we did, VMware wouldn’t be on the list.

Eric

If you have a hardware accelerated graphics card which supports opengl,
you
can get even better speed up:

http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Trample the slow … Hurdle the dead”

Raul S. <raul.siles gmail.com> writes:

with or adjust any control.
Hi,

i have the same Problems on Suse 11.1 and gnuradio 3.1svn.

I solved it by executing with:
$nice -n 19 grc

Regards Markus