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

2012-02-24 Thread Sebastian Döring

On Thu, 23 Feb 2012 10:29:02 -0500
 Tom Rondeau t...@trondeau.com wrote:

On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring
sdoer...@rhrk.uni-kl.dewrote:


Hello,

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.

Thanks.
-Sebastian




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.

Tom



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?


Thanks
-Sebastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

2012-02-23 Thread Tom Rondeau
On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring
sdoer...@rhrk.uni-kl.dewrote:

 Hello,

 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.

 Thanks.
 -Sebastian



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.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio