Re: [Discuss-gnuradio] Interesting performance observations on WX GUI FFT sink
-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- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting performance observations on WX GUI FFT sink
-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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting performance observations on WX GUI FFT sink
-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- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting performance observations on WX GUI FFT sink
On Sun, May 8, 2011 at 10:40 PM, Stefan Gofferje stefan.goffe...@gmx.dewrote: -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. 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 - -- (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- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting performance observations on WX GUI FFT sink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2011 12:52 AM, Tom Rondeau 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- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
