[USRP-users] USRP Buffer Overflow

Michael West michael.west at ettus.com
Fri Nov 20 19:07:31 EST 2015


To add to the discussion, another possibility to alleviate momentary drops
in file I/O throughput is to increase buffering in UHD.  This is
accomplished by increasing the "num_recv_frames" parameter (in the device
address args).  For B2xx, I regularly set it to 512.

Regards,
Michael

On Fri, Nov 20, 2015 at 9:28 AM, Andrew Wells via USRP-users <
usrp-users at lists.ettus.com> wrote:

> The FIFO, along with the realtime scheduling option,  seems to enable us
> to collect at 50 MS/s. Thanks all!
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-bounces at lists.ettus.com] *On Behalf
> Of *Marcus D. Leech via USRP-users
> *Sent:* Thursday, November 19, 2015 7:23 AM
> *To:* Rob Kossler
>
> *Cc:* usrp-users at lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> FIFOs are implemented as ring-buffers in kernel memory.  They aren't huge,
> but they are buffers.  In the very early days of "named pipes" (what FIFOs
> were originally called), the ring buffer was managed on disk, but in Linux,
> it's a RAM-resident ring buffer.
>
>
>
>
>
>
>
>
>
> On 2015-11-19 10:16, Rob Kossler via USRP-users wrote:
>
> Marcus,
>
> Regarding the Unix-style FIFO, it is my understanding that such a FIFO
> does not actually buffer any data.  My understanding is that such a FIFO
> just provides a "connection" between the producer and consumer by way of a
> file.  I think that the consumer will still need to keep up at the
> instantaneous streaming rates (rather than the average streaming rates).
> If true, then I don't think this helps the issue.  Is my understanding
> wrong?  I recall that we had a discussion on this topic several months ago
>
>
>
> Rob
>
>
>
>
>
> On Thu, Nov 19, 2015 at 5:31 AM, Marcus Müller <usrp-users at lists.ettus.com>
> wrote:
>
> Hi Andrew,
> I must admit that I've had long discussions about that and we never came
> quite to a conclusion, but:
> of course you can optimize your system for write performance. Make the
> file system buffers large, don't use a journalling file system, make sure
> GNU Radio is the only one acquiring attention from that disk to make things
> work more "averagely" on the data sink side of things.
> I usually refer people to [1] for tweaking of their file system behavior.
> What I like about that answer is that the author stresses the fact that
> you're trading safety for speed if you're buffering much of your samples in
> RAM.
>
> Another approach that many people find helpful is:
> 1. Making a Unix-style FIFO, e.g. mkfifo /arbitrary/path/fifo
> 2. start writing the contents of that FIFO to the storage (this will block
> until there actually is data), ie. cat /arbitrary/path/fifo >
> /media/ssd/samples.dat (or even "dd if=/arbitrary/path/fifo
> of=/media/ssd/samples.dat bs=<block size in Bytes>", if you want to control
> the write chunk sizes. Try with just cat first.)
> 3. use the file sink with the /arbitrary/path/fifo
>
> Cheers,
> Marcus
>
> [1] http://unix.stackexchange.com/a/41831/106650
>
>
>
> On 19.11.2015 02:25, Andrew Wells wrote:
>
> I tried the raw write test in GNU Radio using the probe rate block and
> found that the data was being written the disk relatively consistently at
> 50 MS/s, but has occasional drops below that rate. This is consistent with
> the overflow we are seeing when collecting data from the USRP. Setting up a
> RAM disc is not a great option for us because we only have 12 GB of ram and
> are looking to run for longer than a minute at a time. Are there any Linux
> specific things we can do stabilize the SSD write rate or prioritize writes
> from GNU Radio?
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-bounces at lists.ettus.com
> <usrp-users-bounces at lists.ettus.com>] *On Behalf Of *Marcus Müller via
> USRP-users
> *Sent:* Wednesday, November 18, 2015 2:47 PM
> *To:* usrp-users at lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Hi Andrew,
>
> Writing to a vector sink should under no circumstances be slower, as that
> really takes but allocation of memory and in-RAM copies, unless you run out
> of RAM, and in fact start writing to disk inadvertedly, by swapping RAM to
> disk.
> However, to fill 10GB (=10*2**30 B, assuming you need 2GB RAM for the rest
> of your system) you'd need quite some samples ie. 10*2^30 B / (4B/S)
> Samples for short complex, or half of that for float complex. That would,
> at 50MS/s, amount to about 53s or 26s, respectively.
> How long is your capture?
>
> Regarding your SSD:
> if you have that installed, run gnome-disks, and have a bit of fun with
> different block sizes; here's two plots for different write block sizes
> (1MB and 1000MB).
> So, if it is really like your SSD is the bottleneck, we can expect the
> work function of that to always find a full buffer, which typically is
> 32KB. If unbuffered is on, that's the granularity with which you ask your
> file system to write stuff away.
>
> If you want to have a raw write test in GNU Radio, connect a constant
> source to "probe rate" block and a file sink.
> If you want much more in-depth analysis of who spends how much time in
> which block: compile GNU Radio with controlport enabled and add at ctrlport
> monitor to your flow graph.
>
> Best regards,
> Marcus
>
> On 18.11.2015 22:55, Andrew Wells via USRP-users wrote:
>
> Thanks! The 'Realtime Scheduling' option allowed us to output to a null
> sync at 50 MS/s, but we are still having issues writing to a file at that
> speed. Outputting to a vector sync seems to be worse than writing to a
> file. Any ideas on how to increase the file write speed?
>
>
>
> System Specs:
>
> RAM: 12 GB
>
> Processor: i7-6500u @ 2.5 GHz
>
> OS: Ubuntu 15.10
>
> SSD: Micron M600 MTFDDAK512MBF (510 MB/s write speed)
>
>
>
>
>
> Andrew
>
>
>
> *From:* James Humphries [mailto:james.humphries at ettus.com
> <james.humphries at ettus.com>]
> *Sent:* Wednesday, November 18, 2015 1:34 PM
> *To:* Andrew Wells
> *Cc:* usrp-users at lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> You may want to try using a tool to set the CPU to maximum performance. I
> use 'indicator-cpufreq'. Make sure there are no power settings that may
> limit CPU. What are you system specs (cpu, ram, etc)?
>
>
>
> You can also try to set 'Realtime Scheduling' in the options block of your
> flowgraph to see if that helps.
>
>
>
> -Trip
>
>
>
> On Wed, Nov 18, 2015 at 4:25 PM, Andrew Wells via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> I tried using a vector sink and reducing the USRP output data to complex
> int16 and the overflow persisted. Even using a null sync still had
> overflow.  I have an SSD that is supposed to be able to write at 460 MB/s,
> so that should not be an issue for the file sync. Anything else I can try?
> I've experienced this issue on two different machines.
>
>
>
> Andrew
>
>
>
> *From:* USRP-users [mailto:usrp-users-bounces at lists.ettus.com] *On Behalf
> Of *Marcus Müller via USRP-users
> *Sent:* Wednesday, November 18, 2015 11:24 AM
> *To:* usrp-users at lists.ettus.com
> *Subject:* Re: [USRP-users] USRP Buffer Overflow
>
>
>
> Try replacing the file sink by e.g. a vector sink. Usually, hard drives
> are much slower at writing than people expect; keeping up with a rate of
> 30MS/s of complex floats means that your hard drive needs to _sustain_ a
> 30MS/s*2float/s*4B/float = 240MB/s
> write rate. That's too much even for many SSDs.
>
> Notice that USB3 performance really depends on a lot of factors, but this
> is the "easiest to diagnose" and "easiest to remedy" one; buffering in RAM
> disk can often solve the problem (and that's exactly what vector_sink does).
>
>
> Best regards,
> Marcus
>
> On 18.11.2015 19:35, Andrew Wells via USRP-users wrote:
>
> Hello,
>
>
>
> I have a simple flowqraph in GNU Radio Companion, which is just a USRP
> source connected to a File Sink.  I'm using a USRP B200 connected by USB
> 3.0 to an Intel USB controller. Based on the chart found at
>
>
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
>
>
> I should be able to sample at up to 61.44 MS/s, but GNU Radio is reporting
> overflow (O's in the console) at sampling rates as low as 30 MS/s. A
> sampling rate of 50 MS/s is critical for my intended application. Are there
> other parts of the system that may be limiting the sample rate or other
> ways to increase it without overflow?
>
>
>
> Thanks,
>
> Andrew Wells
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users at lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users at lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> USRP-users at lists.ettus.com
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151120/7bb7438c/attachment-0002.html>


More information about the USRP-users mailing list