[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] b210 overflows and huge usb buffer

From: Juha Vierinen
Subject: Re: [Discuss-gnuradio] b210 overflows and huge usb buffer
Date: Mon, 12 Jan 2015 17:17:59 +0000

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. 


On Mon, Jan 12, 2015 at 11:30 AM, Jeff Long <address@hidden> wrote:
On 01/11/2015 10:38 PM, Marcus D. Leech wrote:
On 01/11/2015 10:26 PM, Juha Vierinen wrote:

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.


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 mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]