Hello all,
I just measured the time the execution of uhd_rx_cfile.py
takes all together.
I used N=20000, samp-rate=1M and the rest was left to the
default values.
In theory the taking of the samples should take T=N/B=20ms
but I had to discover that the whole process is taking
about 2s.
Does anybody know what exactly is taking so long and if
there is a way to speed it up?
Since I am actually planning to somehow use this script
(or parts of it) in the context of spectrum
sensing/monitoring for dynamic access, 2 seconds is
definitely taking to long.
Thanks in advance.
Sebastian
On 14/12/11 03:21 AM, Sebastian D. wrote:
to speed it up?
Well, there’s loading the Python interpreter, and the shared libraries
it immediately relies on. Then
there’s loading all of the gnuradio and other “stuff” that is
“imported” into your running Python image.
Then there’s creating and starting the flow-graph. Then there’s the
setting-up of the hardware that
UHD has to do on startup. Yup, I can see that taking 2 seconds or
more.
If what you want to do is “set frequency, record some data for awhile,
change to a new frequency,
rinse, repeat”, then you’re better off writing a custom flow-graph
that does that, rather than trying
to “script” something like uhd_rx_file.py. Once a flow-graph is setup
and created, the overhead drops
quite a bit.
I think: gnuradio/gr-uhd/examples/usrp_spectrum_sense.py
Already does a lot of what you want.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On Wed, 14 Dec 2011 07:36:38 -0500
“Marcus D. Leech” [email protected] wrote:
T=N/B=20ms but I had
there’s loading all of the gnuradio and other “stuff”
change to a new frequency,
Already does a lot of what you want.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thanks a lot. Code really looks like what I am looking
for.
Concerning the machine+Python version combinations that
cause seg faults: Is there a known combination that works?
Seems like mine doesn’t.
-Sebastian
On 14/12/11 08:05 AM, Sebastian D. wrote:
Thanks a lot. Code really looks like what I am looking for.
Concerning the machine+Python version combinations that cause seg
faults: Is there a known combination that works?
Seems like mine doesn’t.
-Sebastian
Could you expand on that a bit, please? Perhaps with an error log, and
what you were trying to do when
you got a segfault?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On Wed, 14 Dec 2011 08:28:57 -0500
“Marcus D. Leech” [email protected] wrote:
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
I was simply trying to test the script
(usrp_spectrum_sense.py 2.4G 2.41G).
I have reproduced the error using gdb and this is what I
get:
Starting program: /usr/bin/python usrp_spectrum_sense.py
2.4G 2.41G
[Thread debugging using libthread_db enabled]
linux; GNU C++ version 4.4.3; Boost_104000;
UHD_003.004.000-71810ad
Warning: this is known to have issues on some
machines+Python version combinations to seg fault due to
the callback in bin_statitics. If you figure out why, we’d
love to hear about it!
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
[New Thread 0xb6afbb70 (LWP 8791)]
[New Thread 0xb62fab70 (LWP 8792)]
gain = 49.5
[New Thread 0xb5a99b70 (LWP 8793)]
[New Thread 0xb5298b70 (LWP 8794)]
[New Thread 0xb4a56b70 (LWP 8795)]
[New Thread 0xb40ffb70 (LWP 8796)]
[New Thread 0xb38feb70 (LWP 8797)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb38feb70 (LWP 8797)]
0x0013a455 in [email protected]@GLIBC_2.1 () from
/lib/tls/i686/cmov/libpthread.so.0
The backtrace says:
#0 0x0013a455 in [email protected]@GLIBC_2.1 () from
/lib/tls/i686/cmov/libpthread.so.0
#1 0x0810ab61 in PyThread_release_lock (lock=0x0) at
…/Python/thread_pthread.h:374
#2 0x080dbad3 in PyEval_ReleaseLock () at
…/Python/ceval.c:262
#3 0x00fa6073 in gr_py_feval_dd::calleval(double) ()
from
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so
#4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay()
()
from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#5 0x0083a788 in gr_bin_statistics_f::work(int,
std::vector<void const*, std::allocator<void const*> >&,
std::vector<void*, std::allocator<void*> >&) () from
/usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#6 0x007d70e7 in gr_sync_block::general_work(int,
std::vector<int, std::allocator >&, std::vector<void
const*, std::allocator<void const*> >&, std::vector<void*,
std::allocator<void*> >&) ()
from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#7 0x007ba475 in gr_block_executor::run_one_iteration()
()
from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#8 0x007da549 in
gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr<gr_block>)
()
from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#9 0x007d3fcd in
boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
void>::invoke(boost::detail::function::function_buffer&)
() from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
#10 0x009515f5 in
boost::detail::thread_data<boost::function0 >::run()
()
from /usr/local/lib/libgruel-3.5.0rc0.so.0.0.0
#11 0x009db7c5 in thread_proxy () from
/usr/lib/libboost_thread.so.1.40.0
#12 0x0013396e in start_thread () from
/lib/tls/i686/cmov/libpthread.so.0
#13 0x003f1a4e in clone () from
/lib/tls/i686/cmov/libc.so.6
Hello,
judging from the log, it seems that a value conversion to float is going
wrong, but my (uneducated) guess the root cause is a race between
threads (this script starts quite a number of threads …?).
I would try to enter larger values for the delays (tune, dwelling delay)
and see whether it changes something. This should reduce the probability
that two threads want to do different things at the same time.
–Matthias
Am 20.12.2011 um 11:11 schrieb Sebastian D.:
On Tue, 20 Dec 2011 11:39:39 +0100
Matthias W. [email protected] wrote:
to do different things at the same time.
Thanks for your answer but unfortunately this did not work
either.
I tried it with up to almost 100 times the actual values
but the result remains the same.
Hello list,
since I got no answer to my last post, I guess what I
wrote wasnt that helpful.
I apologize for whatever I did not understand, but I am
not familiar with error logs in the context of the problem
I have here.
I would really appreciate any help with this.
Once again my problem: I am getting the famous
segmentation fault when trying to launch the
usrp_spectrum_sense.py-script.
When asked for an error log, I simply launched it in GDB
and copy pasted the output plus backtrace.
My OS is Ubuntu 10.04, running on a 32-bit machine.
Default python version is 2.6. My hardware is the USRP
N210 with XCVR2450.
I tried to change my default python version (tried 2.5 and
2.7) but it did not help ( but I am also not sure if I
have changed all the necessary paths correctly).
Nevertheless I returned to 2.6 and have even reinstalled
the GNUraduio package (using the build-script) -->
nothing changed.
uhd_fft.py and so on is working but I really need to get
the above mentioned script running, to modify it later on.
Thanks in advance for your answers.
-Sebastian
On Thu, 15 Dec 2011 12:40:02 +0100
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian D.
[email protected] wrote:
#0 0x0013a455 in [email protected]@GLIBC_2.1 () from
/lib/tls/i686/cmov/libpthread.so.0
#1 0x0810ab61 in PyThread_release_lock (lock=0x0) at
…/Python/thread_pthread.h:374
#2 0x080dbad3 in PyEval_ReleaseLock () at …/Python/ceval.c:262
#3 0x00fa6073 in gr_py_feval_dd::calleval(double) ()
This is likely a similar issue with the Python GIL (global interpreter
lock) that occurred previously on the E100. In that case the final
cause was a missing ctypes library.
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-June/001479.html
To find out, try this thread hack. The patch is old, so you will
probably need to apply manually against the current master.
diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py
index 70f530f…31bf458 100644
— a/uhd_spectrum_sense_sum.py
+++ b/uhd_spectrum_sense_sum.py
@@ -32,7 +32,11 @@ import sys
import math
import struct
import time
+import threading
+class ThreadClass(threading.Thread):
class tune(gr.feval_dd):
“”"
@@ -306,6 +310,9 @@ def main_loop(tb):
if name == ‘main’:
On Tue, 20 Dec 2011 20:24:28 -0500
Tom R. [email protected] wrote:
…/Python/thread_pthread.h:374
— a/uhd_spectrum_sense_sum.py
try:
outstanding issue in GNU Radio for a while. It’d be good
to get a fix for
it in.
Thanks,
Tom
Thank you guys - it worked!
The line positions have a changed a bit and so I simply
attached the new code (gnuradio build 20.12.2011).
— a/usrp_spectrum_sense.py 2011-12-20 12:44:55.000000000
+0100
+++ b/usrp_spectrum_sense.py 2011-12-21 14:26:19.252873684
+0100
@@ -28,9 +28,14 @@
import sys
import math
import struct
+import threading
sys.stderr.write(“Warning: this is known to have issues
on some machines+Python version combinations to seg fault
due to the callback in bin_statitics. If you figure out
why, we’d love to hear about it!\n”)
+class ThreadClass(threading.Thread):
-
def run(self):
-
return
-
class tune(gr.feval_dd):
“”"
This class allows C++ code to callback into python.
@@ -240,6 +245,9 @@
if name == ‘main’:
-
t = ThreadClass()
-
t.start()
-
tb = my_top_block()
try:
tb.start()
Regards
Sebastian
On Tue, Dec 20, 2011 at 11:02 AM, Thomas T. [email protected] wrote:
diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py
- def run(self):
- tb = my_top_block()
try:
tb.start() # start executing flow graph in
another thread…
Thomas
Please let us know if this patch works. I think this has been an
outstanding issue in GNU Radio for a while. It’d be good to get a fix
for
it in.
Thanks,
Tom
On Wed, Dec 21, 2011 at 8:36 AM, Sebastian D.
[email protected]wrote:
import math
class tune(gr.feval_dd):
try:
tb.start()
Regards
Sebastian
Sebastian, thanks for the report!
Tom T., thanks for the patch! I updated the code in maint/master/next.
It
worked on my machine, too. If anyone who wants to use
usrp_spectrum_sense.py and has more issues, please let us know.
Tom