Forum: GNU Radio Profiling, stopping the flow graph

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3dfb724cefc1eddbade1e8bd1ee6131f?d=identicon&s=25 Dan Halperin (Guest)
on 2007-01-29 19:37
(Received via mailing list)
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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-01-29 20:28
(Received via mailing list)
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.

>         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
3dfb724cefc1eddbade1e8bd1ee6131f?d=identicon&s=25 Dan Halperin (Guest)
on 2007-01-29 20:42
(Received via mailing list)
Eric Blossom 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
This topic is locked and can not be replied to.