I managed to find a solution to this. I create a ram filesystem (tmpfs) and dump fixed length files there with gnuradio. I then move the files when they are complete to a persistent drive using another script. I don't know why I didn't think of this before.
juha On Mon, Jan 12, 2015 at 11:30 AM, Jeff Long <willco...@gmail.com> wrote: > On 01/11/2015 10:38 PM, Marcus D. Leech wrote: > >> On 01/11/2015 10:26 PM, Juha Vierinen wrote: >> >>> Hi, >>> >>> Now that the b210 timing issue now solved (thanks to Ian and Balint!), >>> I'm trying to get samples to disk at about 50 MHz. I have more than >>> >> > I've streamed through programs like mbuffer before, to iron out an uneven > disk recording rate. But I can't say I understand all of the GR and Linux > buffering interaction well enough to be sure why it worked. > > > the required bandwidth on the disk, but there are occasional I/O >>> hiccups. With the N2x0 I just set the recv_buff_size to 1e9 and that >>> solves pretty much all the I/O hangups I get. With the b210 there >>> seems to be a driver imposed limit on the number of receive frames >>> however, which prevent me from increasing num_recv_frames above 2000. >>> At higher values, I get a uhd driver error and no samples come out of >>> the uhd source. How can I increase the usb buffers on the b210 to >>> about 1-2 GB? I don't care about latency, I just want to avoid long >>> gaps in the data that are caused by the disk occasionally hanging up. >>> I have tested the b210 with a null sink and there are no dropped packets. >>> >>> I've tried everything to reduce disk hangups by changing the >>> filesystem cache settings with some limited help, but I still can't >>> completely remove occasional usb 3.0 packet drops. I'm convinced that >>> simply using a multi gigabyte buffer is the easy way out solution, but >>> I can't make this happen with the current uhd driver. >>> >>> juha >>> >>> Those limits are likely not imposed by UHD, per se, but by underlying >> libusb implementation details, and the drivers in the kernel that "feed" >> libusb, and then >> the hardware USB controllers. >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
