Was quite a while since I last looked into GNU Radio’s Performance Counters [1]. Turns out, they changed quite a bit. The current implementation is no longer based on the strange ICE framework, but uses Apache Thrift. I guess there are good reasons for this, but the user experience, certainly, was not the driving force :-)

As far as I see, GNU Radio requires Thirft 0.9.2, which is not even part of the most recent Ubuntu release. Since I didn’t find a PPA, I installed packages that are seemingly from one of the developers.

Once Thrift is installed, you should run cmake again and assert that thrift is explicitly listed in the activated components, since only gr-ctrlport does not do anything.

-- ######################################################
-- # Gnuradio enabled components                         
-- ######################################################
--   * python-support
--   * testing-support
--   * volk
--   * gnuradio-runtime
--   * gr-ctrlport
--   * * thrift      <----- !!!!
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fec
[...]

Under OSX it looked better in the beginning, as I found an up to date Thrift in homebrew. That was, however, not too successful either; it caused very strange compile errors that could only be resolved by switching to C++11. Compiling GNU Radio with C++11, in turn, also didn’t work since recent commits broke C++11-support… After fixing some variable declarations it finally compiled.

Once everything is installed, Performance Counters can be enabled in ~/.gnuradio/config.conf like so

[ControlPort]
on = True
edges_list = True

[PerfCounters]
on = True
export = True

Now, when you start a flow graph you should see a new message with the port that exposes the interface to the flow graph’s controls and performance counters. Look for something like

INFO: Apache Thrift: -h tronn -p 62735

Note, you don’t have to change the flow graph for this message to appear. You can, however, add a Ctrlport Monitor, which automatically starts a GUI interface whenever the flow graph is started. The GUI connects to the Control Port interface of the flow graph and allows to get and set the different values.

Performance Measurement

What I actually wanted to measure was the cumulative CPU time of the individual blocks of my WiFi receiver. This is interesting since it allows to identify bottlenecks and get a bit of an understanding how it will scale with bandwidth and the number of frames per second.

I updated my tool that connects to a flow graph and dumps the values into a CSV. If you are interested, it is part of gr-foo—the project where I dump blocks that are not project specific.

I made a non-GUI version of my WiFi receiver flow graph and used it to receive 435 byte frames with a rate of 10 frames per second. With my 2011 MacBook Air this worked without any overruns (even though the load was pretty high). The distribution of the cumulative CPU time looked like this:

The colors correspond to the different parts of the receiver. The first part—labeled Stream-based—contains the blocks that do frame detection. These blocks have to process all samples and, thus, their load scales linearly with the bandwidth of the signal. The second part—labeled Frame-based—is triggered when a frame is detected and, of course, scales with the number of frames per second and some also with the length of the payload.

1. T. W. Rondeau, T. O’Shea, and N. Goergen, “Inspecting GNU Radio Applications with ControlPort and Performance Counters,” in ACM SIGCOMM 2013, 2nd ACM SIGCOMM Workshop of Software Radio Implementation Forum (SRIF 2013). Hong Kong, China: ACM, August 2013, pp. 65–70.

• reddit
• twitter
• facebook
• google+