Re: [Discuss-gnuradio] Strange uhd::device::send execution times

[Gaetano Mendola]

On Sun, Jun 19, 2011 at 8:01 PM, Josh Blum <address@hidden> wrote:
>
>
> On 06/19/2011 02:55 AM, Gaetano Mendola wrote:
>> 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.
>
> 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.


-- 
cpp-today.blogspot.com