# Struggling with gr-perf-monitorx **URL:** \ **Category:** GNU Radio\ **Created:** [June 17, 2015, 5:12am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344 "2015-06-17T05:12:50Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [June 17, 2015, 5:12am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/1 "2015-06-17T05:12:50Z")
I have this “nearly” working. MX brings up a window, connects to GRC, briefly displays a graph, then blanks out. Displayed in the command line window: gr-perf-monitorx: radio.getKnobs threw exception (math domain error). … (repeats) I’m not sure what that message is telling me in the operation/debug domain. Clue please. The paper “Inspecting GNU Radio Applications with ControlPort and Performance Counters” shows various blocks in Figures 2 and 5 named “Ctrlport…”. Are those necessary for MX? I haven’t found anything that indicates yes or no. Clue please. Operationally: root@Tori-Radio:~/thrift# gnuradio-companion --version GNU Radio Companion v3.7.7.1-131-g71ab508d root@Tori-Radio:~/thrift# lsb\_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 15.04 Release: 15.04 Codename: vivid ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [June 17, 2015, 5:44am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/2 "2015-06-17T05:44:59Z")
On Tue, Jun 16, 2015 at 11:11 PM, Dennis G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > domain. Clue please. > > root@Tori-Radio:~/thrift# lsb\_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 15.04 > Release: 15.04 > Codename: vivid I’m not sure what MX is? Are you using that as shorthand for gr-perf-monitorx? If that’s the case, then no, the Ctrlport Probes are there for other purposes and not necessary for Performance Monitor. I’m seen that Math Domain error before, but I’ve never been able to replicate it reliably. I think it’s something related to a divide by zero and I think happens when one block’s performance measure of work time comes back with 0 – which doesn’t often happen. Are you using any of your own blocks in the flowgraph? What if you run the Controlport Monitor tool instead of Performance Monitor? That will just show you a list of all available parameters exposed by the application over ControlPort. Tom ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [June 17, 2015, 6:02am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/3 "2015-06-17T06:02:30Z")
On Tue, 2015-06-16 at 23:43 -0400, Tom R. wrote: > ``` > error). > named > root@Tori-Radio:~/thrift# lsb_release -a > > ``` > > gr-perf-monitorx? Yes. > just show you a list of all available parameters exposed by the > application over ControlPort. I have a chain that includes three custom blocks whose load diminishes as work flows down the chain. I can post the graph, if that helps. ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [June 17, 2015, 6:28am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/4 "2015-06-17T06:28:48Z")
On Tue, 2015-06-16 at 23:43 -0400, Tom R. wrote: > ``` > error). > named > root@Tori-Radio:~/thrift# lsb_release -a > > ``` > > gr-perf-monitorx? > any of your own blocks in the flowgraph? What if you run the > Controlport Monitor tool instead of Performance Monitor? That will > just show you a list of all available parameters exposed by the > application over ControlPort. That’s an interesting tool. Thanks for pointing it out. I’m looking for why I am getting "O"s on the console but I don’t see full buffers (worst is 9%). I assume I’m doing something pragmatically stupid or graph stupid, which is the usual case. What does “nproduced -2.0” mean? Is there a paper somewhere? While I’m asking stupid questions, :), it would be handy for this tool to spit out something textual so I can post-process, such as graphing a parameter. Is that possible? I don’t see anything obvious in the immediate Python code. Perhaps I should also mention two things. First, I’ve only been working with GRC for a few months and I’m not signals literate. Second, I’m processing samples using OpenMP (in some cases nested) plus some data structures background maintenance threads, and written in C++11. Seems to all work fine. Not sure that matters. SDR is HackRF. I wasn’t seeing Os with bladeRF. ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [June 17, 2015, 11:19am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/5 "2015-06-17T11:19:44Z")
Hi Dennis, > I’m looking for why I am getting "O"s on the console but I don’t see > full buffers (worst is 9%). I assume I’m doing something pragmatically > stupid or graph stupid, which is the usual case. > SDR is HackRF. I wasn’t seeing Os with bladeRF. > I can really only tell from the USRP side of life [1], but since we’re > talking about hardware: This could happen because if, after the source block has produced a number of samples that it took from the hardware, it needs to be called again to be able to get more samples. If that “calling again” doesn’t happen, at some points, the receive buffers flow over. The calling again, however, will only happen if GNU Radio sees reason for it, which would typically mean that something in the output buffer reader changed. If, for example, the block that you connect to the source, just sits there and blocks in its (general\_)work(), there’s no chance that it could yet take more input data – and hence, GNU Radio doesn’t ask for more samples from the source. If that’s the case, try to connect a null sink in parallel to the first block after the source. Does that change things. > What does “nproduced -2.0” mean? Is there a paper somewhere? > I’d rather point you to the right source directly [2]. I don’t really > know why that appears; it’s a “magic value” that your block’s > (general\_)work can return to tell the scheduler that the return value is > not the number of items that were produced, and that the significant > number is the sum of items that were specified using produce()[3] calls. > > While I’m asking stupid questions, :), > still waiting for your first 🙂 > it would be handy for this tool > to spit out something textual so I can post-process, such as graphing a > parameter. Is that possible? I don’t see anything obvious in the > immediate Python code. > Well, the idea is that controlport allows you to more or less easily > write your own clients that just directly ask. Now, there’s two things: > if you need something specific, it might be easier to just write a > client of your own. > If you want to be awesome, and think your visualization or output > facility is helpful for anyone but you, too, you might want to work with > gr-perf-monitorx’s source code itself and make upstream pull requests – > it’s very seldom that GNU Radio can’t use a GUI developer 🙂 > Perhaps I should also mention two things. First, I’ve only been working > with GRC for a few months and I’m not signals literate. > Well, I think you’re becoming more and more literate 🙂 > Second, I’m processing samples using OpenMP (in some cases nested) plus some > data > structures background maintenance threads, and written in C++11. Seems > to all work fine. Not sure that matters. > It’s generally cool to see someone do additional acceleration! OpenMP > sounds exiting, as it covers a field that differs from the “raw” > data-parallelism that VOLK[4] tries to achieve using SIMD on different > platforms. What’s your application’s purpose? Greetings, Marcus [1] Idle, Eric: Why to permanently consider the less strenuous side of existence, in: Proceedings of the Life of Brian, final notes, 1978. Editors: Chapman, Cleese, Gilliam, Idle, Jones, Palin. [2] > [3] > **[GNU Radio Manual and C++ API Reference: gr::block Class Reference](https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html)** [4] [http://libvolk.org](http://libvolk.org) ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [September 5, 2015, 5:49am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/6 "2015-09-05T05:49:52Z")
Hey Tom, I ran into this “math domain error” with CtrlPort recently. Based on your suggestion that it might be related to zero work blocks causing a divide by zero, I started hacking away anything that might be being short-circuited in the relatively complex flowgraph. First, an shorted branch of a select tree - no dice. Then a copy block. BAM! That was it. I guess copy must be super efficient and not really do any work. Anyhow, I figure that using a copy block in a fg should reliably reproduce this problem an perhaps serve as a model for working around it. In my fg, the copy block was serving as a valve that would prevent downstream blocks from executing if it was shut. In my case, the “valve” was open, and data was flowing through the copy block. Thanks! ---
**Author:** ![Dennis\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/838e76/32.png) [@Dennis\_G](https://www.ruby-forum.com/u/Dennis_G)\ **Post date:** [September 6, 2015, 7:35am UTC](https://www.ruby-forum.com/t/struggling-with-gr-perf-monitorx/242344/7 "2015-09-06T07:35:44Z")
It looks like this also applies to blocks that have been “bypassed.” Makes sense.