On Sun, Jun 19, 2011 at 8:01 PM, Josh Blum <j...@ettus.com> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
