[USRP-users] rx_samples_to_file issue
pwitkowski at gmail.com
Fri Oct 3 09:26:09 EDT 2014
To say that the issue is just because the disk subsystem can't keep up is a
bit of cop-out.
I had issues writing to disk when the incoming stream was 400MB/s and my
RAID0 system was benchmarked at being much higher than that.
The issue that I've been seeing stems from the fact that it appears that
you cannot concurrently read/write from the data stream as its coming in.
In effect you have a main loop that reads from the device and then
immediately tries to write that buffer to file. If you do not complete
these operations in a timely fashion overflows occur.
One way to solve (or at least band aid the issue) is to set your
dirty_background_ratio to 0. I was able to get writing to disk working
somewhat with this setting as it is more predictable to directly write to
disk instead of having your write cache fill up and then having a large
amount of data to push to disk. That said, my RAID0 array is capable of
such speeds and even then I was getting a few (but much reduced) overflows.
The one surefire way I know of getting this working (even on a slow disk
system) is to buffer the data. The buffer can then be consumed by the disk
writing process while being concurrently added onto by the device reader.
The easiest way to test buffering (that I've found) is to simply set up a
GNURadio Companion program with a stream-to-vector block between the USRP
and file sink blocks. This is exactly what I am doing currently since even
with a very powerful system, I could not get data saved to disk quickly
enough given the aforementioned issues with the provided UHD software.
On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users <
usrp-users at lists.ettus.com> wrote:
> Thanks Marcus for your replies. Yes O gone away.
> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com> wrote:
>> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3,
>> 4GB ram, it gave me
>> some OOOO but was lesser than earlier, but I do not understand, my most
>> of the ram capacity and processor was sitting idle while it shows OOOO, why
>> is this strange behaviour
>> The default format for uhd_rx_cfile is complex-float, thus doubling the
>> amount of data written compared to rx_samples_to_file.
>> You can't just use CPU usage as an indicator of loading--if you're
>> writing to disk, the disk subsystem may be much slower than you think, so
>> "rate limiting step" is writes to the disk, not computational elements.
>> Try using /dev/null as the file that you write to. If the 'O' go away,
>> even at higher sampling rates, then it's your disk subsystem.
>> using uhd_rx_cfile getting similar result, but strangely, why it is
>> low, at 4M sampling rate it was higher???
>> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <mleech at ripnet.com>
>>> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>>> Yes I am running single channel, but when trying to achieve my desired
>>> sampling rate without _4rx.rbf, it says, requested sampling rate is not
>>> valid, adjusting to some 3.9M or so.
>>> sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
>>> with 64 bit, but getting same result on both machines
>>> Here is my command to capture signal:
>>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
>>> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>>> and here is its output:
>>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
>>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>>> -- Opening a USRP1 device...
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>>> -- Using FPGA clock rate of 52.000000MHz...
>>> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0)
>>> failed to make default spec - ValueError: The subdevice specification "A:0"
>>> is too long.*
>>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>> Don't use the _4rx image if you don't need it.
>>> The USRP1 only does strict-integer resampling, and with a master clock
>>> (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
>>> that it can produce. Try 5.2Msps or 4.3333Msps.
>>> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
>>> needs to be able to sustain that for at least as long as the capture lasts.
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
> USRP-users mailing list
> USRP-users at lists.ettus.com
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users