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, <mle...@ripnet.com> 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: ------ [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
