[USRP-users] Buffer overflow tips

Андрій Хома anik123wb at gmail.com
Wed Oct 25 04:32:48 EDT 2017


Continuation here:
http://ettus.80997.x6.nabble.com/USRP-users-libusb-uses-only-one-thread-tc7609.html

2017-10-10 20:14 GMT+03:00 Андрій Хома <anik123wb at gmail.com>:

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


More information about the USRP-users mailing list