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
