# Strange uhd::device::send execution times **URL:** \ **Category:** GNU Radio\ **Created:** [June 19, 2011, 12:00pm UTC](https://www.ruby-forum.com/t/strange-uhd-send-execution-times/208463 "2011-06-19T12:00:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [June 19, 2011, 12:00pm UTC](https://www.ruby-forum.com/t/strange-uhd-send-execution-times/208463/1 "2011-06-19T12:00:38Z")
Hi all, I’m observing strange execution times calling the method uhd::device::send. The tx rate I’m using is 12.5 Mega samples per seconds and the method send is called with 45000 samples, given the sample rate and the amount of samples passed to this function I expect an execution time less than 0.0036 seconds per call. However as you can see in the attached image, the execution time is either around 0.0026 or around 0.005 seconds. When this (still strange to me this dual value) happens the transmissions is a successful transmission. Some time however the executions times are much higher than those as you can see in the second image attached (corrupted\_tx.gif), when this happens I see some “U” in the console and the transmission is corrupted. As you can see the execution times have a singular pattern: 0.1, 0.2, 0.3, 0.4 seconds or normal values ( \< 0.0036 ). I use the send method with io\_type equal to COMPLEX\_FLOAT32 and send mode equal to SEND\_MODE\_FULL\_BUFF. Is there a way to optimize the send execution time (not giving float32 but int16 for example) ? And why sometime the send lasts all that time ? Regards Gaetano M. ---
**Author:** ![Gaetano\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/45deac/32.png) [@Gaetano\_M](https://www.ruby-forum.com/u/Gaetano_M)\ **Post date:** [June 20, 2011, 1:37pm UTC](https://www.ruby-forum.com/t/strange-uhd-send-execution-times/208463/2 "2011-06-20T13:37:00Z")
On Sun, Jun 19, 2011 at 8:01 PM, Josh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I believe that you are seeing the affect of buffering in the device. > There is a 1mb SRAM on the device which can buffer milliseconds worth of > TX data. > > Due to buffering, a call to send() could take less time than it takes to > transmit the data at the expected sample rate. Due to flow control, a > call to send() could take longer than expected (if data is already > available in the buffer). Does that explain your observations? > > You may want to run your tests for a longer duration to mitigate the > effect of buffering and flow control. That’s can explain the different times when the transmission doesn’t result to be corrupted. The expected send time is 0.0036 seconds and I get executions time of 0.0026 or 0.005. Some time the send method lasts 0.1 second, 0.2 second, 0.3 second, 0.4 second (look at the other plot I sent to have an idea ) it seems I have a false sharing with another thread performing I/O from disk. Tomorrow I’ll try to do a cpu affinity for the internal UHD thread, I have 12 cores on my server, and I fear the kernel is juggling that thread around. The input vector allignment can have an impact on performances ? G. – > **[c++ today](http://cpp-today.blogspot.com)** > > "Almost" day by day thoughts on code inspected ---
**Author:** ![Gaetano\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/45deac/32.png) [@Gaetano\_M](https://www.ruby-forum.com/u/Gaetano_M)\ **Post date:** [June 21, 2011, 9:20am UTC](https://www.ruby-forum.com/t/strange-uhd-send-execution-times/208463/3 "2011-06-21T09:20:19Z")
On Sun, Jun 19, 2011 at 8:44 PM, Gaetano M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I have 12 cores on my server, and I fear the kernel is juggling that thread > around. I have solved the issue but still I’m not happy at all with what is going on. The samples I’m feeding with the USRP N210 are stored on a disk, my sample rate is 12.5 mega samples per second so in order to maintain that rate for hours I have a thread performing I/O from disk and a thread feeding the radio device. The server is a dual socket xeon system and when the two threads are scheduled on the same socket then the uhd::device::send some time lasts too much (some time even 2 seconds vs the 0.0036 extimated). To solve the issue I had to perform a cpu affinity for the thread inside the UHD library and a cpu affinity for my own thread in order to have those two threads on different sockets (core 7 for uhd thread and core 2 for my own thread). Unfortunaly there is no way to specify at the time of the device on which core the thread has to run, I’ll see if I can submit a patch that will permit to build a device like this: “address=127.0.0.1,send\_buff\_size=100e6,lockcore=7” Regards Gaetano M. – > **[c++ today](http://cpp-today.blogspot.com)** > > "Almost" day by day thoughts on code inspected