B210 overflows and huge usb buffer

GNU Radio
1

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

2

On 01/11/2015 10:26 PM, Juha V. wrote:

the uhd source. How can I increase the usb buffers on the b210 to
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.

3

On 01/11/2015 10:38 PM, Marcus D. Leech wrote:

On 01/11/2015 10:26 PM, Juha V. 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.

4

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

5

On 01/12/2015 12:17 PM, Juha V. wrote:

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
One of the issues with USB (of any flavour) is that it wasn’t designed
with bulk performance in mind, really, so you have to kind of stand on
your
head to get it.

Near as I can tell, in the USB driver world (at least on Linux), the
driver (via libusb) doesn’t buffer the same way that is done in the
networking-stack.
There’s no way to configure a seriously-huge buffer for traffic
that’s in-flight.