Re: [Discuss-gnuradio] Profiling, stopping the flow graph

[Eric Blossom]

On Mon, Jan 29, 2007 at 10:35:33AM -0800, Dan Halperin 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.

> 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

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