Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink

[mleech]

Leave "unbuffered" = OFF.   This flag was added for "slow" file-sinks, when, for example, you're writing slow data to an external process via somehthing like FIFO, and you don't want the default stdio buffering to get in the way.  The default, if you leave it off, is to use stdio buffering.

The "bursts of O" behaviour is to be expected, depending on how much RAM the kernel allocates to write-behind buffers, and how fast your disk subsystem is.   Your writes get posted to the kernel.  The kernel throws them into a usually-immense, write-behind cache.  When its I/O scheduler decides its time to commit those writes, things slow down.

You might try also using num_recv_frames on the device arguments (if you aren't already), to try and smooth out the flow from the USB controller.

You might also compare what you're doing with something that doesn't use Gnu Radio at all, such as rx_samples_to_file.

 

 

On 2015-05-07 14:01, Murphy, John wrote:

On Thu, May 7, 2015 at 1:01 PM,  <address@hidden> wrote:

If you want high file-write performance, leave it in buffered mode.

Also, a 175-tap filter, running at 16Msps is going to chew up a lot of CPU. How about a simple low-pass filter, decim=2? Make the transition bandwidth fairly sloppy.

Or alternatively, just run the USRP at your desired sample-rate into the file-sink.

I presume you mean buffered mode on the File Sink? With the wording of
the param, I can not understand wether buffered mode is "Unbuffered =
off" or "Unbuffered = on". Do you know which it is? Also the doc page
indicates this param is not passed to the make function, so I am not
even sure it is really used.

Transition bandwidth is sloppy, double the (sample rate minus
two-sided passband width), or in this case something on the order of
1/4 the input sample rate.
CPU usage is 7% (total for all processes on the machine) with this
whole flowgraph running. It is a polyphase filter which is more
efficient, although with decim only 2 my guess is there are only two
polyphase arms so the FIR decim only used a CPU of about 9% for the
same set of taps. And same buffer overrun problem with the FIR decim
as the PFB. But still.

I and my co-wrokers have all these same issues every time we try this
for the past year with flowgraphs with just the two blocks... USRP
Source and File Sink. So I am not sure the filter or the CPU usage is
an issue at all here.
To find out, I just now tried it again, disabled everything but the
USRP Source and the File Sink, changing the USRP output format to
complex int16, and within 90 seconds I got an overrun. The CPU usage
in this mode is about 3% or 4% total.

Also note I am talking about the flowgraph running fine for a minute
or so then getting a handful (1, maybe 3 or 4) 'O's. Then another
minute or so with another burst of O's. Etc. It is not a huge thing
but when you are doing stuff like testing synchronizers or signal
recovery it is enough to be a problem. On something like GPS playback
for a test bench the hiccups make it completely unworkable.

- John

How would I best set up a UHD Source block for USRP B2x0 devices to output to a flowgraph that uses a File Sink block to write to disk without overflows (and how would I best set up the File Sink block)? This is the attached system hardware, dedicated to GR... Gigabyte GB-BXi7-4770R Brix Pro PC Crucial Ballistix Sport 2x8=16GB RAM DDR3L-1600 (PC3L-12800) CL9 Timing 9-9-9-24 Samsung 840 EVO 250GB SATA-III internal 2.5" SSD ...so a lot of overkill on hardware resources, but no knowledge on how to set up the UHD Source block or File Sink block to take advantage of this. I am attempting to record data at 16Ms/s on the USRP and 8Ms/s to the disk but I would like to take this even higher (perhaps as high as 28 Ms/s on the USRP or as fast as I can get it) if possible with a fast enough system. Fedora 20 with LXDE (uname -r is 3.18.9-100.fc20.x86_64) UHD is 3.8.1 GR is 3.7.6.1 My flowgraph has: a. UHD USRP Source with master clock 32M, sample rate 16M, wire format auto, output type complex float32, and a device argument of num_recv_frames=512. b. Polyphase Decimator with decim 2, 175 taps from firdes.low_pass_2(), FFT rotator and filters. c. Constant multiply by 32768 with type complex. d. Complex to IShort with vector output yes. e. File Sink with input type short, vector length of 2, unbuffered on (there's a confusing parameter name, which I am not sure actually does anything), and append file overwrite.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio