Peak Hold in FFT display causing UI problems

I have an Atom D-510 running Fedora 12, and the latest UHD+GnuRadio (as
of this morning).

I’ve noticed that if I turn on “Peak Hold” in the FFT display, the
entire input side of the GUI becomes
unresponsive to input, even for low input bandwidths, where the CPU
usage is quite low.

Anyone else seen this?

I can easily reproduce this with a simple:

UHD:Single-USRP source ------> FFT Sink (Update rate 5, Averaging on,
Peak Hold on)

It doesn’t seem to depend on input bandwidth–even as low as 250KHz
input bandwidth, setting Peak Hold
causes the GUI to become unresponsive (although the FFT display
continues to update).


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

On Tue, Oct 12, 2010 at 04:31:38PM -0400, Marcus D. Leech wrote:

I have an Atom D-510 running Fedora 12, and the latest UHD+GnuRadio (as
of this morning).

I’ve noticed that if I turn on “Peak Hold” in the FFT display, the
entire input side of the GUI becomes
unresponsive to input, even for low input bandwidths, where the CPU
usage is quite low.

Anyone else seen this?

Yes, I’ve seen this.

Eric

On 10/12/2010 05:14 PM, Eric B. wrote:

Yes, I’ve seen this.

Eric

Any speculation about why this is?

If you look at the code, it uses numpy.maximum(a,b) to compute the max
function over the vector. But unless numpy.maximum()
is implemented in a completely-stupid way, I can’t see it being
“computey” enough to cause this issue.

I noticed that if I lowered the update rate to 2, it started working
again. Three was no good, as was four. Five, was right out.

Maybe an OpenGL weirdness on that particular platform, since my other
machine, which only has about 50% more “go” than
the Atom D-510 doesn’t have this problem, even for the same GnuRadio
versions.


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

On 10/12/2010 06:56 PM, Josh B. wrote:

Peak hold is essentially doubling the number of vertexes to draw. If
you double the number of bins, do you get the same behavior?

You may increase performance by dropping the frame rate to lowering
the number of bins.

-Josh

Yup, doubling the number of bins puts it in the same territory.


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

On 10/12/2010 06:56 PM, Josh B. wrote:

Peak hold is essentially doubling the number of vertexes to draw. If
you double the number of bins, do you get the same behavior?

You may increase performance by dropping the frame rate to lowering
the number of bins.

-Josh

So, curiously enough, on my other dual-core machine, running
nearly-identical Gnu Radio, and Fedora release, and with
only-somewhat-beefier
CPU, I have an app that runs 6 ‘scope’ traces simultaneously, and
updates once per second. It doesn’t have this problem.


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

Peak hold is essentially doubling the number of vertexes to draw. If you
double the number of bins, do you get the same behavior?

You may increase performance by dropping the frame rate to lowering the
number of bins.

-Josh

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