I have been using the WX GUI FFT Sink for a while now and I notice,
regardless of the power of the machine, setting an FFT above 4096 causes
it to effectively grind to a halt and UI become grey.
Is this a python thing? Or is there a way to accelerate this block???
Regards,
Mark McCarron
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
Try cranking the frame-rate down to 5.
I figured that one out, but why is the performance so poor?
In other applications, I can push over half a million samples without
causing issues.
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:51:56 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I have been using the WX GUI FFT Sink for a while
now and I notice, regardless of the power of the machine,
setting an FFT above 4096 causes it to effectively grind to a
halt and UI become grey.
Is this a python thing? Or is there a way to accelerate this
block???
Regards,
Mark McCarron
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Try cranking the frame-rate down to 5.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
I figured that one out, but why is the performance so poor?
In other applications, I can push over half a million samples without
causing issues.Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it’s quite a low rate, then with a large number of bins, there may be
no way to achieve the given frame rate, given the sample rate, and FFT
size.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
Also, the attached works just fine at a 5e6 sample rate, 4096 FFT bins,
and update rate of 10Hz.
Marcus,
Sorry for the late reply on this, I’ve been upgrading my hardware and
I’m just catching up. Here is my issue, in Spectrum lab if I provide a
FFT Input length of 65536 on a 192Ksps stream, I get the following
characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz … 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink,
it basically hangs. Do you know why?
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From: [email protected]
To: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Marcus,
I have run some tests and it looks like the WX GUI FFT Sink stops
responding with any settings above 4096@15 FPS.
I’ve upgrade my video card drivers and they work fine with everything
else. Processor usage is fine, nothing in the event logs.
Regards,
Mark McCarron
From: [email protected]
To: [email protected]
Subject: RE: [Discuss-gnuradio] WX GUI FFT Sink Performance
Date: Thu, 16 May 2013 06:21:34 +0100
Marcus,
Sorry for the late reply on this, I’ve been upgrading my hardware and
I’m just catching up. Here is my issue, in Spectrum lab if I provide a
FFT Input length of 65536 on a 192Ksps stream, I get the following
characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz … 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink,
it basically hangs. Do you know why?
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From: [email protected]
To: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Max freq range: 0.00000 Hz … 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %It runs quite fast. If I provide the same FFT size to WX GUI FFT
sink, it basically hangs. Do you know why?Regards,
Mark McCarron
Because apparently SpectrumLab is using an overlapped FFT
implementation. The one in wXGUI doesn’t. Further, the wxGUI
implmentation has far
too much Python involved in processing samples, so trying to process
65536 samples at a time is likely sluggish, to the point that it can’t
keep
up in real time.
The underlying FFT implementation itself is very fast–Gnu Radio uses
FFTW.
I’ve regularly built FFT filters with 250e3 taps, and they are able to
run in real time with sample rates into the many Msps.
So, if you do the math, a non-overlapped FFT implementation of 65536
bins at 192Ksps means 2.92 FFTs/second. If the display update rate is
more than that, there’s no way to actually produce an update rate
faster than 2 per second under those circumstances, with a
non-overlapped
FFT.
Marcus,
Thanks, that would explain the slow updates that I was seeing. Perhaps
an overlapped FFT would be useful for interactive scenarios. Has one
been implemented?
This, however, does not explain why my windows are not responding.
After about 8 seconds, the window turns to grey and the GUI of the FFT
becomes frozen.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 09:49:59 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
Sorry for the late reply on this, I've been upgrading my
hardware and I'm just catching up. Here is my issue, in
Spectrum lab if I provide a FFT Input length of 65536 on a
192Ksps stream, I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz .. 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI
FFT sink, it basically hangs. Do you know why?
Regards,
Mark McCarron
Because apparently SpectrumLab is using an overlapped FFT
implementation. The one in wXGUI doesn't. Further, the wxGUI
implmentation has far
too much Python involved in processing samples, so trying to
process 65536 samples at a time is likely sluggish, to the point
that it can't keep
up in real time.
The underlying FFT implementation itself is very fast--Gnu Radio
uses FFTW.
I've regularly built FFT filters with 250e3 taps, and they are able
to run in real time with sample rates into the many Msps.
So, if you do the math, a non-overlapped FFT implementation of 65536
bins at 192Ksps means 2.92 FFTs/second. If the display update rate
is
more than that, there's no way to actually produce an update rate
faster than 2 per second under those circumstances, with a
non-overlapped
FFT.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Marcus,
Thanks, that would explain the slow updates that I was seeing.
Perhaps an overlapped FFT would be useful for interactive scenarios.
Has one been implemented?
I think they’re implementing an overlapped-FFT option for the QtGUI
sinks for “next”. Not sure. The thing about overlapped display FFTs is
that you’re
trading (sometimes significant) temporal accuracy of the estimate for
display-update-rate.
Further, given that your display is only probably 1280 pixels wide, I
fail to see how you expect to extract any more “useful” information from
a
65536-bin FFT that must necessarily lose information when it’s
mapped to a narrow display. The wxGUI tools don’t support scrolled FFT
windows,
so they necessarily drop bins to satisfy the display requirement.
There are three common “strategies” for mapping a many-binned FFT into
a
smaller display window:
o drop bins
o select peak
o average bins
All of those options lose information in the display.
Internally, of course, for signal processing and data recording
purposes, you can have FFTs that are very wide.
The other thing to consider is that ALL the GUI widgets that are “wired
in” to Gnu Radio were designed primarily for debugging/instrumentation
purposes–akin to sticking a voltmeter or oscilloscope on your
circuit board. The problem is that they’re just barely “good
enough” to construct
applications with, and so there’s a natural expectation that they
implement all the GUI thingies you might even want to attach to a
signal-processing
stream.
There is zero requirement that you use the built-in GUI widgets.
Lots of applications have been built that use the Gnu Radio
signal-processing path,
and completely-different approaches to providing a GUI–GQRX is one
such example, and my own IRA software uses an XFORMS based GUI, with
a Gnu Radio signal flow underneath.
The QtGUI widgets in “next” are, I understand, substantially enhanced
over the current set in “master”, so perhaps we can see some more
elegant applications written with the Gnu Radio built-in GUI bits.
This, however, does not explain why my windows are not responding.
After about 8 seconds, the window turns to grey and the GUI of the FFT
becomes frozen.
That’s generally because your flow-graph has some structural problem
that is causing the GUI thread to fail to get any cycles.
On 05/16/2013 12:41 PM, Mark McCarron wrote:
Marcus,
Thanks for highlighting the limitations of the current
implementation. It explains a lot. Personally, I would like to see a
little more emphasis on useful GUI elements, not just accurate GUI
elements.
So, you’d rather see fast updates of near-complete-nonsense, than slow
updates of accurate data?
In regards to the WX GUI FFT window not responding. I have tested it
with a very simple flow-graph. A USRP source and the WX FFT GUI
block. If the settings are at 4096@15fps, it works fine, try anything
higher and the windows greys out. So, I don’t really see where the
issue is.
Works for me with the latest Gnu Radio on F14.
You may just be running out of computational steam in Python land, since
the wxGUI FFT sink does waaaay too much of its “stuff” in Python land.
Python runs up to about 100 times slower than equivalent native code.
I’ve attached a simple test that works just fine here.
Marcus,
Thanks for highlighting the limitations of the current implementation.
It explains a lot. Personally, I would like to see a little more
emphasis on useful GUI elements, not just accurate GUI elements.
In regards to the WX GUI FFT window not responding. I have tested it
with a very simple flow-graph. A USRP source and the WX FFT GUI block.
If the settings are at 4096@15fps, it works fine, try anything higher
and the windows greys out. So, I don’t really see where the issue is.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 11:59:33 -0400
From: [email protected]
To: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
Thanks, that would explain the slow updates that I was seeing.
Perhaps an overlapped FFT would be useful for interactive
scenarios. Has one been implemented?
I think they're implementing an overlapped-FFT option for the QtGUI
sinks for "next". Not sure. The thing about overlapped display
FFTs is that you're
trading (sometimes significant) temporal accuracy of the estimate
for display-update-rate.
Further, given that your display is only probably 1280 pixels wide,
I fail to see how you expect to extract any more "useful"
information from a
65536-bin FFT that must necessarily *lose* information when it's
mapped to a narrow display. The wxGUI tools don't support scrolled
FFT windows,
so they necessarily drop bins to satisfy the display requirement.
There are three common "strategies" for mapping a many-binned FFT
into a
smaller display window:
o drop bins
o select peak
o average bins
All of those options lose information in the display.
Internally, of course, for signal processing and data recording
purposes, you can have FFTs that are very wide.
The other thing to consider is that ALL the GUI widgets that are
"wired in" to Gnu Radio were designed *primarily* for
debugging/instrumentation
purposes--akin to sticking a voltmeter or oscilloscope on your
circuit board. The problem is that they're *just barely* "good
enough" to construct
applications with, and so there's a natural expectation that they
implement all the GUI thingies you might even want to attach to a
signal-processing
stream.
There is *zero* requirement that you use the built-in GUI widgets.
Lots of applications have been built that use the Gnu Radio
signal-processing path,
and completely-different approaches to providing a GUI--GQRX is
one such example, and my own IRA software uses an XFORMS based GUI,
with
a Gnu Radio signal flow underneath.
The QtGUI widgets in "next" are, I understand, substantially
enhanced over the current set in "master", so perhaps we can see
some more
elegant applications written with the Gnu Radio built-in GUI bits.
This, however, does not explain why my windows are not
responding. After about 8 seconds, the window turns to grey and
the GUI of the FFT becomes frozen.
That's generally because your flow-graph has some structural problem
that is causing the GUI thread to fail to get any cycles.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Marcus,
Accurate output is great when doing analysis, but if you just want to
create a quick interface that will allow you to see a little more
detail, then overlapping or duplicating the stream is fine. The error
in the output is always within a given tolerance and that can be
suitable for a lot of applications. By no means am I suggesting to
eliminate the accurate GUI elements, just that an alternative should be
offered.
I tested your sample and that works fine on my machine. I have updated
it to a refresh rate of 30 and this is when it becomes unresponsive. I
ran perfmon and the resources seem fine, but I do see a massive spike
in page faults and transition faults when executing a flow graph. That,
in itself may not be an issues, but I have checked all the usual
bottlenecks and they are barely being touched. I’m running the latest
Windows build of this on a quad core Win2012 server with 16GB ram.
It seems like a bug in the build.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:02:09 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
On 05/16/2013 12:41 PM, Mark McCarron wrote:
Marcus,
Thanks for highlighting the limitations of the current
implementation. It explains a lot. Personally, I would like to
see a little more emphasis on useful GUI elements, not just
accurate GUI elements.
So, you'd rather see fast updates of near-complete-nonsense, than
slow updates of accurate data? :) :)
In regards to the WX GUI FFT window not responding. I have
tested it with a very simple flow-graph. A USRP source and the
WX FFT GUI block. If the settings are at 4096@15fps, it works
fine, try anything higher and the windows greys out. So, I
don't really see where the issue is.
Works for me with the latest Gnu Radio on F14.
You may just be running out of computational steam in Python land,
since the wxGUI FFT sink does waaaay too much of its "stuff" in
Python land.
Python runs up to about 100 times slower than equivalent native
code.
I've attached a simple test that works just fine here.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 05/16/2013 01:36 PM, Mark McCarron wrote:
I tested your sample and that works fine on my machine. I have
Regards,Mark McCarron
More likely a bug in the Windows wxGUI implementation, which is known to
have lots of flaws.
I assumed you were running this on Linux, which is the primary
development platform for Gnu Radio.
One of the beauties of open-source software is that if you don’t like
the
way something works, or think it should be
enhanced, you can take care of that yourself, and, hopefully, share
the
results with the community.
If you don’t have the necessary skils to do so, then you make your
desires
known, and hope that the developers
will, at some point, consider your needs, and decide whether it’s
worth
implementing them, and putting said
implementation on the schedule.
I think Marcus had previously stated that the GUI elements in Gnu Radio
itself were primarily designed as an aid
to instrumenting and debugging flow-graphs, and that only secondarily
are
they useful for building real applications.
It would be useful for Tom to chime in here about the features of the
QtGUI
stuff in “next”. Nobody is actively
working to make the wxGUI side of things “lovely” at this point,
because
energy is going into, as far as I know,
the QtGUI side.
I don’t really care which GUI framework is used, just that it works.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:56:51 -0400
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
From: [email protected]
To: [email protected]
CC: [email protected]
One of the beauties of open-source software is that if you don’t like
the way something works, or think it should be
enhanced, you can take care of that yourself, and, hopefully, share
the results with the community.
If you don’t have the necessary skils to do so, then you make your
desires known, and hope that the developers
will, at some point, consider your needs, and decide whether it’s
worth implementing them, and putting said
implementation on the schedule.
I think Marcus had previously stated that the GUI elements in Gnu Radio
itself were primarily designed as an aid
to instrumenting and debugging flow-graphs, and that only secondarily
are they useful for building real applications.
It would be useful for Tom to chime in here about the features of the
QtGUI stuff in “next”. Nobody is actively
working to make the wxGUI side of things “lovely” at this point,
because energy is going into, as far as I know,
the QtGUI side.
On Thu, May 16, 2013 at 1:36 PM, Mark McCarron
[email protected] wrote:
Marcus,
Accurate output is great when doing analysis, but if you just want to
create a quick interface that will allow you to see a little more
detail, then overlapping or duplicating the stream is fine. The error
in the output is always within a given tolerance and that can be
suitable for a lot of applications. By no means am I suggesting to
eliminate the accurate GUI elements, just that an alternative should be
offered.
I tested your sample and that works fine on my machine. I have updated
it to a refresh rate of 30 and this is when it becomes unresponsive. I
ran perfmon and the resources seem fine, but I do see a massive spike
in page faults and transition faults when executing a flow graph. That,
in itself may not be an issues, but I have checked all the usual
bottlenecks and they are barely being touched. I’m running the latest
Windows build of this on a quad core Win2012 server with 16GB ram.
It seems like a bug in the build.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:02:09 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
On 05/16/2013 12:41 PM, Mark McCarron wrote:
Marcus,
Thanks for highlighting the limitations of the current
implementation. It explains a lot. Personally, I would like to
see a little more emphasis on useful GUI elements, not just
accurate GUI elements.
So, you'd rather see fast updates of near-complete-nonsense, than
slow updates of accurate data? :) :)
In regards to the WX GUI FFT window not responding. I have
tested it with a very simple flow-graph. A USRP source and the
WX FFT GUI block. If the settings are at 4096@15fps, it works
fine, try anything higher and the windows greys out. So, I
don't really see where the issue is.
Works for me with the latest Gnu Radio on F14.
You may just be running out of computational steam in Python land,
since the wxGUI FFT sink does waaaay too much of its "stuff" in
Python land.
Python runs up to about 100 times slower than equivalent native
code.
I've attached a simple test that works just fine here.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
Marcus,
I have tested this under the Ubuntu LiveUSB on a couple of machine and
the same problem occurs every time.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:48:01 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
On 05/16/2013 01:36 PM, Mark McCarron wrote:
Marcus,
Accurate output is great when doing analysis, but if you just
want to create a quick interface that will allow you to see a
little more detail, then overlapping or duplicating the stream
is fine. The error in the output is always within a given
tolerance and that can be suitable for a lot of applications.
By no means am I suggesting to eliminate the accurate GUI
elements, just that an alternative should be offered.
I tested your sample and that works fine on my machine. I have
updated it to a refresh rate of 30 and this is when it becomes
unresponsive. I ran perfmon and the resources seem fine, but I
do see a massive spike in page faults and transition faults when
executing a flow graph. That, in itself may not be an issues,
but I have checked all the usual bottlenecks and they are barely
being touched. I'm running the latest Windows build of this on
a quad core Win2012 server with 16GB ram.
It seems like a bug in the build.
Regards,
Mark McCarron
More likely a bug in the Windows wxGUI implementation, which is
known to have lots of flaws.
I assumed you were running this on Linux, which is the primary
development platform for Gnu Radio.
--
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Marcus,
I have tested this under the Ubuntu LiveUSB on a couple of machine and
the same problem occurs every time.Regards,
Mark McCarron
The problem stems from the fact that too much of the internal machinery
in the wxGUI graphical sinks are computed in Python.
For long FFTs, and even modest update rates, those computations take
longer than is strictly healthy for dealing with the arrival of
new samples, so the GUI thread gets wedged.
Again, given the fact that your display geometry is likely less than
1280 wide, you’ll simply lose information for FFTs larger than that.
But I’ve
already said that.
On 17-05-13 02:22, Marcus D. Leech wrote:
Again, given the fact that your display geometry is likely less than
1280 wide, you’ll simply lose information for FFTs larger than that.
I one is looking for weak CW signals, in a waterfall, wouldn’t a wide
bin, make this signal invisible in among the noise? If more bins fit in
one pixel, there could be a mode where the bin with the most power is
displayed. If this is complete non-sense, how would you implement
looking for faint cw carriers, in like EME applications?
Gr. Simon
On 05/28/2013 01:28 PM, Simon IJskes wrote:
Gr. Simon
There are a number of ways to do this. One can make a scrollable FFT
window – either waterfall or plot.
One can use various “compression” techniques to reduce the much-wider
FFT data to the number of displayable bins you have. There are three
in common use:
o strictly decimate the bins -- keep-one-in-N bins
o average input bins together to make a display bin
o pick the highest power in a given bin set to make a display bin
I believe that the wxGUI widgets in Gnu Radio do the first
one–keep-one-in-N
I agree it would be useful for the FFT display widgets to have more
options for processing FFTs that are wider than the display.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs