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.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
|