Interesting performance observations on WX GUI FFT sink

I was doing some experiments with multi-DDC support in recent UHD+USRP2
firmware.

I thought I’d start by a simple source----->FFT Sink

I discovered rather by accident that if my FFT sinks had averaging
turned OFF, that even at
modest input bandwidths on my dual-centrino laptop, they’d get wedged,
even at relatively-low
FFT frame rates (3 for example). But turn on averaging, and the
systems resources required
were reduced to the point that the display could support FFT display.
I think this says something
about how (in) efficient OpenGL is about rendering even simple 2D
objects that change dynamically.

Another test I did was:

source----->LOG-POWER FFT---->NULL SINK

The resources consumed by that were about 30% of what they were when I
was actually displaying
an FFT window.


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/08/2011 11:50 PM, Marcus D. Leech wrote:

I discovered rather by accident that if my FFT sinks had averaging
turned OFF, that even at
modest input bandwidths on my dual-centrino laptop, they’d get wedged,
even at relatively-low
FFT frame rates (3 for example). But turn on averaging, and the
systems resources required
were reduced to the point that the display could support FFT display.
I think this says something
about how (in) efficient OpenGL is about rendering even simple 2D
objects that change dynamically.

I have similar observations but without any hardware. The WX FFT totally
locks my Athlon 64 3800+, when displaying.

Just signal source -> FFT sink.

BUT - only the WX FFT. The QT FFT seems rather reasonable in performance
demands.


(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk3HDcUACgkQbQKZlCdPOMMgBgCdFZnkjXIKmsiEVI8JmrsjHRX5
AYwAn1YT+cl9SrsG8Z/iuZvrsaoxQC7q
=AHue
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
I have similar observations but without any hardware. The WX FFT totally
locks my Athlon 64 3800+, when displaying.

Just signal source -> FFT sink.

BUT - only the WX FFT. The QT FFT seems rather reasonable in performance
demands.

Try turning down the display rate in the WX FFT display–by default it’s
set to 30 FPS. I generally run mine with
5 FPS or less, and turn on averaging, with an alpha of 0.1 or
smaller.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 12:44 AM, Marcus D. Leech wrote:

Try turning down the display rate in the WX FFT display–by default it’s
set to 30 FPS. I generally run mine with
5 FPS or less, and turn on averaging, with an alpha of 0.1 or smaller.

Yeah, at 2-3 FPS I am around 75-85% CPU…
But still I’m wondering why the QT sink is not so performance-hungry…


(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk3HECwACgkQbQKZlCdPOMNd+QCghnz1v6VFRvx8H8beFZKRdQEN
aPQAoKjGyLQFtOTeMICsAoLwSdz8spDP
=aqrk
-----END PGP SIGNATURE-----

On Sun, May 8, 2011 at 10:40 PM, Stefan Gofferje
[email protected]wrote:

were reduced to the point that the display could support FFT display.
demands.

Stefan,
Are you saying you’re using a gr_sig_source straight into the FFT sink?
You
should probably put a gr_throttle block in there since you have nothing
else
rate-limiting the flowgraph.

It’s not a surprise that the Qt sinks are more efficient, though. The
wxPython has a lot of stuff implemented directly in Python where as the
QtGui is almost entirely done in C++.

Tom

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/09/2011 12:52 AM, Tom R. wrote:

Are you saying you’re using a gr_sig_source straight into the FFT sink?
You should probably put a gr_throttle block in there since you have
nothing else rate-limiting the flowgraph.

It’s not a surprise that the Qt sinks are more efficient, though. The
wxPython has a lot of stuff implemented directly in Python where as the
QtGui is almost entirely done in C++.

Of course, I used a throttle :).


(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk3HEmIACgkQbQKZlCdPOMO8MACfSy7mrp+MX8CwqXuFKc5N6C5i
slcAoIS5c7bY4HV8GZ4lsrPMVnyVWBGw
=Ep7Q
-----END PGP SIGNATURE-----

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs