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.
On Sun, Jun 19, 2011 at 8:01 PM, Josh B. [email protected] 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.
–
On Sun, Jun 19, 2011 at 8:44 PM, Gaetano M. [email protected]
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.
–