[USRP-users] Buffer overflow tips

Андрій Хома anik123wb at gmail.com
Tue Oct 10 13:14:59 EDT 2017

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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171010/9794567f/attachment-0002.html>

More information about the USRP-users mailing list