On 09/07/2014 07:08 PM, Peter Witkowski wrote:
Not sure I follow. If I have a large enough buffer, the data coming
in and the data coming out should be free of concurrency issues and
should be able to work just fine. That is, as long as the producer
thread can keep adding data to the message queue, I should be OK. If
it gets locked out due to concurrency issues, I can see that this is
where there could be issues (e.g., I drop packets because the producer
thread can't push data since it's locked out of the message queue).
Also, a large enough buffer could also alleviate the issue all
together since I would be able to record for hours before the overflow
would take place.
My sample rates are on the order of 400 MB/s (well within PCIe x4
spec). Also, my RAID array has been benchmarked to handle roughly 800
MB/s. The flow-graph is nothing more than a USRP source tied into a
File Meta Sink.
Certainly, if you could somehow put together *hours* of buffering at
400MB/sec, you'd be in good shape, provided you don't exceed that buffer.
But, well, at 400MB per second, 10 seconds is 4GB, 100 seconds is
400GB, etc. Pretty soon you run out of DRAM.
So, at 100Msps, you'll have a hard time on most systems. Try just
writing with rx_samples_to_file (a UHD-only example that comes with
UHD), which avoids Gnu Radio overheads entirely. But really,
recording at 100Msps (400MB/sec in your example) is challenging, even if
you don't do much with the samples. Gnu Radio adds some overhead
that you probably don't need just to record samples.
On Sun, Sep 7, 2014 at 4:35 PM, Marcus D. Leech <mle...@ripnet.com
<mailto:mle...@ripnet.com>> wrote:
On 09/07/2014 04:24 PM, Peter Witkowski wrote:
Hello,
I have a simple application written in Python using GNURadio.
All I am trying to accomplish is to have the USRP data be written
to disk. The application works fine when I dump data to
/dev/null or run it at reduced sampling rates. However, when I
run at my desired sampling rate, I have a good amount of buffer
overflows (a series of "O" characters get printed).
The host machine that I am working on should have no problems
sampling at the higher rates, but I have found a curious issue in
that not a whole lot of memory is used up by my GNURadio application.
As a result, I am wondering if there is any way to tell GNURadio
to use larger buffers (on the order of a few GB) in order to
prevent data from being dropped. I noted that there seem to be
several function calls available in the C++ API, but there seems
to be a limited set of these calls in the Python wrappers.
Latency is a non-issue for me at the moment, but I need to
capture all the data without dropping a large amount of data.
Note that I have the code running with "real-time" priorities in
Linux.
Thanks for your help. FYI I am running GNURadio on Ubuntu
14.04. Also, I know that my RAID set-up is capable of writing to
disk at twice the rate of data coming in per benchmarking the HDDs.
--
Peter Witkowski
pwitkow...@gmail.com <mailto:pwitkow...@gmail.com>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Adding buffering for long-term recording simply delays, by a few
seconds, that point at which your system cannot keep up.
What sample rates are you trying to record? What does your
flow-graph look like?
Buffering is useful to allow you to "ride through" short-term
shortfalls in the ability to handle samples. It is useless for
handling the situation
where your long-term ability to keep up falls short of what you
actually need.
Have you tried setting up a ramdisk, and writing to that?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
--
Peter Witkowski
pwitkow...@gmail.com <mailto:pwitkow...@gmail.com>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
