I brought this up some time ago, but no one was able
to help me. I have a little more information now, so
maybe we can make progress.
In the application we are working on, we would like to
perform continuous split-second captures from the USRP
over days at a time. Unfortunately, it hangs after an
indeterminate amount of time. The power of the
computer running the program seems to have some
bearing on the time before crash, but it is still
pretty random. We have run times from 2min to 23hrs.
I wrote a simple script to reproduce the bug. All it
does is record from the USRP to a vector for .1 sec,
then throws the vector away. Tracing the problem, I
find that top_block.run() calls
top_block_run_unlocked(*args), which calls
_gnuradio_swig_py_runtime.top_block_run_unlocked(*args),
which never returns. I haven’t traced it any farther
as that last appears to be a compiled C++ library, and
I wouldn’t know where the source is.
Any help in relieving my ignorance would be
appreciated.
Thanks,
John B.
Texas A&M-Commerce
____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
John B. wrote:
pretty random. We have run times from 2min to 23hrs.
I wouldn’t know where the source is.
Any help in relieving my ignorance would be
appreciated.
Thanks,
John B.
Texas A&M-Commerce
Just FYI, my Radio Astronomy stuff runs for weeks at a time at my
place, continuously capturing gigabytes of spectral and
total-power data, and it never hangs. Unless I muck with the hardware
at the dish with the receiver turned on. Then the
hardware sometimes gets upset, but I regularly have this stuff running
for looong periods of time without incident.
That probably doesn’t help, other than to know that it’s possible to
do stuff with the USRP for weeks at a time without
any noticeable problems…
John B. wrote:
pretty random. We have run times from 2min to 23hrs.
I had a similar problem and it was really nasty to figure out, as far as
I remember it turns out it was due to memory fragmentation in the Kernel
USB buffer causing the USB bus to be starved of data. I think it was
Johnathan and Eric that tracked it down so they might have more
information.
Possibly more importantly the fix was to change the usrp.source to
include fusb_block_size=4096 and fusb_nblock=16.
Hope that helps.
Toby
On Wed, Nov 28, 2007 at 02:29:48PM -0800, John B. wrote:
I wrote a simple script to reproduce the bug. All it
does is record from the USRP to a vector for .1 sec,
then throws the vector away. Tracing the problem, I
find that top_block.run() calls
top_block_run_unlocked(*args), which calls
_gnuradio_swig_py_runtime.top_block_run_unlocked(*args),
which never returns. I haven’t traced it any farther
as that last appears to be a compiled C++ library, and
I wouldn’t know where the source is.
Can you post a link to the script please?
Eric
John-
pretty random. We have run times from 2min to 23hrs.
By “continuous split-second captures” do you mean that you run a series
of small
(brief) captures? How short is split-second?
By “power of the computer”, I assume you mean performance, not power
capacity. What
ranges of CPU clockrate / num cores are you trying?
-Jeff