[USRP-users] Buffer overflow tips

Marcus Müller marcus.mueller at ettus.com
Sat Oct 14 13:31:41 EDT 2017

Hi Andrew,

Your English is extremely fine, don't apologize!

270 MS/s is really *a lot* of data. You'd need a very capable computer
even when just handling that amount of data internally, but with
USB-connected devices, you also get a lot of interrupt handling. That
will put additional load on your CPU. I'm therefore actually very amazed
by the fact that the processor simply managing to deal with that! But:
you must make sure you're not only counting the time the program itself
is running, but also the time the CPU is stuck in kernel mode, handling
the interrupts, and the data transfers. Did you do that?

205 MS/s (or more so, 270 MS/s) is *extremely much* for a storage
system. That is more than 16 Gb/s, or, in other words, more than three
full SATAIII connections running at maximum utilisation. You do have an
impressive set of SSDs, there, if you can sustain that write rate.

> The write stream waits until a new buffer appears in the write queue,
> otherwise it sleeps for several milliseconds. If the buffer is
> located, it immediately writes it to the named FIFO file.
How large are your buffers? I mean, with 4KB buffers, and 32b/S = 4B/S
(assuming you use 16bit I + 16bit Q) it follows that a single 4KB packet
can hold 1024 Samples, and that at 41 MS/s, that happens rougly every
1024 S / (41 MS/s) ~= 25 µs. For things to take "several milliseconds",
your buffers need to be Megabytes in size.

What does help is that the OS buffers named pipes as well as the file
system in RAM. If overflows happen roughly after your free RAM would
have been eaten up by the 205 MS/s · 4B/S = 820 MB/s, then your storage
isn't actually up to the task of writing data as the USRPs are at
producing it, and buffering by the OS simply saves you for "as long as
the bucket does not overflow".

Hope that helped,

On 10.10.2017 19:14, Андрій Хома via USRP-users wrote:
> Hello,
> I apologize for my terrible English,
> I have a problem with buffer overflow.
> Tell me, please, what optimization measures do you use when working?
> How the problem is observed:
> I have 6 b205mini devices, and I noticed that I was up to a maximum of
> 205MHz per second. ie, either 5 devices on 41 MHz, or 6 devices on 34
> MHz. If more - overflow.
> What I undertook:
> First I used the foul language, then I tried to write my solution in C
> ++, which allowed me to throw read and write operations into separate
> streams.
> The thread doing the reading basically only does what it expects at
> the end of the blocking function rx_stream-> recv, and then quickly
> throws the resulting buffer into the write queue.
> The write stream waits until a new buffer appears in the write queue,
> otherwise it sleeps for several milliseconds. If the buffer is
> located, it immediately writes it to the named FIFO file.
> It turns out that these two streams can not interfere with each other.
> At the same time, as a bonus, additional insurance is obtained in the
> form of a queue of buffers if the receiving party (which reads named
> FIFO files and does nothing) will not succeed.
> Beefers who spin in the queue are re-used, which means that no extra
> time is spent to create them.
> Next, I set the priority
> uhd :: set_thread_priority_safe (1.0, true);
> All this manipulation allowed me, in some way, to "undo" the time of
> the onset of overflow. But not at the expense of the queue of buffers:
> when the overflow comes it is clear that the queue has not overflowed,
> the receiving party manages to process incoming data to it.
> And in the implementation of the foul language, and in the
> implementation of C ++, I do not observe any strong consumption of CPU
> resources. It turns out, the processor manages.
> Further, if I in C ++ do not write the result (the stream writing data
> to files - will not write them =)) - then I get a new limit value -
> now the limit is already ~ 270MHz.
> How so?
> Therefore, the question can be formulated as follows:
> 1 Why does the limit in 205 MHz arise? Really because of the name of
> the model?))
> 2 If the limit exists, then why does C ++ implementation still give
> some "bonus" in the form of a more recent overflow occurrence? What
> can be the reason for this limit and how to understand its nature? How
> to explain the weak CPU consumption?
> And yet, as I said at the beginning: all possible good practices are
> interesting when working with USRP
> For additional information:
> The motherboard Z10PE-D16 WS (can it matter in the chipset?)
> Intel xeon e5-2430v4 processor
> Memory DDR4 1866
> Thanks for taking the time,
> I will be glad to receive a response,
> With all respect, Andrew.
> _______________________________________________
> 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/20171014/20142788/attachment-0002.html>

More information about the USRP-users mailing list