[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Duration of Calculations in Python scripts

From: Sebastian Döring
Subject: Re: [Discuss-gnuradio] Duration of Calculations in Python scripts
Date: Fri, 24 Feb 2012 12:57:54 +0100

On Thu, 23 Feb 2012 10:29:02 -0500
 Tom Rondeau <address@hidden> wrote:
On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring


in the context of spectrum sensing in the 2.4 GHz band using a modified version of the usrp_spectrum_sense.py script, I am having problems with
high latency times.
Since the time for recording samples and all the tuning stuff is supposed to be much less than what I am currently dealing with (something around
88ms between two center frequencies),
I was wondering if this might be a problem of some additional calculations the python script is doing with every message I get from the c++ code. In particular these calculations contain summing up the vector I get from the queue of the source and comparing the sum to a previously calculated
threshold wrapped into some if-statements

Any statements highly appreciated.


If it's latency in the flowgraph, you can try and use the new max_noutput_items (pass this value to tb.start(N) or tb.run(N), whichever is being used). The smaller this number, the faster blocks will pass data between eachother, but also the harder your computer is going to have to
work to keep up.

If you think that the latency is due to Python calculations, you can think about finding a more efficient scipy implementation of the calculations. If one doesn't exist, you can write some C code and look at the f2py program that comes with Python; it's a simpler wrapper generator than SWIG that converts from FORTAN to Python, but I believe it nicely supports C
functions as well.

Just a couple of thoughts.


Thanks Tom,

I have proofed your suggestions, but none of them seemed to help much.

I also ran the script under cProfile to get a better timing analysis and it turns out that "gr_py_msg_queue__delete_head" is the real evildoer. According to cProfile it takes 94ms per call. Since cProfile produces some overhead itself, this is pretty much what fits into these almost 90ms I measured myself. Does anyone have an idea if and how this could be speeded up?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]