Profiling, stopping the flow graph

GNU Radio
1

Hi,

What options are there for profiling GNU Radio code? I’ve done some
Python profiling, and some C profiling, but what options are there for
this crazy SWIG-driven mix of the two?

Also, a flow graph question. In the main loop of the transmit path of my
benchmarking program, I have the following (hopefully self-explanatory
code):

    fg.start()

    self.num_to_send = options.packets
    self.bytes_per_packet = options.bytes
    util.rand_init(options.seed)

    for i in range(self.num_to_send):
        # generate random payload here into buf
        buf = util.random_bytes(self.bytes_per_packet)
        if i % 10 == 0:
            print "> sending packet #", i
        mac.send_buffer_unreliably(buf)

sleep(.01)

sleep (1)

sys.exit(0)

    fg.stop()     # tell flow graph to stop.
    fg.wait()     # wait for it to finish

If the sleep(.01) line is uncommented, then the flow graph does not
stop, and instead I quit using the sleep(1); sys.exit(0); however
everything works fine with no sleeping. What could be causing this? Is
it something weird involving code running in the same thread that
shouldn’t be?

Thanks,

Dan

2

On Mon, Jan 29, 2007 at 10:35:33AM -0800, Dan H. wrote:

Hi,

What options are there for profiling GNU Radio code? I’ve done some
Python profiling, and some C profiling, but what options are there for
this crazy SWIG-driven mix of the two?

Oprofile (oprofile.sf.net) kicks ass. It’ll profile anything
including our Python and C++ and the kernel, without having to add
instrumentation to the generated code. It uses the hardware
performance counters.

    for i in range(self.num_to_send):
    fg.stop()     # tell flow graph to stop.
    fg.wait()     # wait for it to finish

If the sleep(.01) line is uncommented, then the flow graph does not
stop, and instead I quit using the sleep(1); sys.exit(0); however
everything works fine with no sleeping. What could be causing this? Is
it something weird involving code running in the same thread that
shouldn’t be?

Thanks,
Dan

Is the receiver code in the same program? If so, the flow graph code
won’t exit until both indicate they are done.

Do you understand the use of the eof flag in
gnuradio-examples/python/usrp/digital/benchmark_tx.py?

It ends up sending (in pkt.py (send_pkt)) a special message (type == 1
vs type == 0) to the gr.message_source that feeds the modulator. The
special message tells the source that we’re not sending any more data.
This results in the C++ code telling the scheduler that it’s done, and
ultimately the flow graph stops.

Also, from this fragment I’m not sure if you are invoking the sleep(3)
function or the time.sleep function. You definitely want the latter.

Eric

3

Eric B. wrote:

including our Python and C++ and the kernel, without having to add
instrumentation to the generated code. It uses the hardware
performance counters.

Awesome, I’ll check it out. Thanks! (At the moment, having trouble
getting it started under Ubuntu…).

    for i in range(self.num_to_send):
    fg.stop()     # tell flow graph to stop.

This results in the C++ code telling the scheduler that it’s done, and
ultimately the flow graph stops.

That was the problem; I’m an idiot. I forgot to copy that line from the
original program. Thanks.

Also, from this fragment I’m not sure if you are invoking the sleep(3)
function or the time.sleep function. You definitely want the latter.

The latter.

Thanks for your help,

Dan