# B210 overflows and huge usb buffer **URL:** \ **Category:** GNU Radio\ **Created:** [January 12, 2015, 4:28am UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785 "2015-01-12T04:28:32Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 12, 2015, 4:28am UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785/1 "2015-01-12T04:28:32Z")
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 ---
**Author:** ![Juha\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/4af34b/32.png) [@Juha\_V](https://www.ruby-forum.com/u/Juha_V)\ **Post date:** [January 12, 2015, 4:44am UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785/2 "2015-01-12T04:44:32Z")
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. ---
**Author:** ![Juha\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/4af34b/32.png) [@Juha\_V](https://www.ruby-forum.com/u/Juha_V)\ **Post date:** [January 12, 2015, 12:31pm UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785/3 "2015-01-12T12:31:23Z")
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. ---
**Author:** ![Juha\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/4af34b/32.png) [@Juha\_V](https://www.ruby-forum.com/u/Juha_V)\ **Post date:** [January 12, 2015, 6:19pm UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785/4 "2015-01-12T18:19:33Z")
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 ---
**Author:** ![Juha\_V](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/4af34b/32.png) [@Juha\_V](https://www.ruby-forum.com/u/Juha_V)\ **Post date:** [January 12, 2015, 6:24pm UTC](https://www.ruby-forum.com/t/b210-overflows-and-huge-usb-buffer/233785/5 "2015-01-12T18:24:21Z")
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.