[USRP-users] Retuning time explodes over time
dario.fertonani at gmail.com
Thu Oct 8 11:10:16 EDT 2015
Interesting debug info...
The explosion in retuning time (and CPU usage) doesn't happen if the
frequencies are closer. For example, running the code attached in my
previous message (carrier freq values in MHz), I get an explosion here
./retuneTest 1728 739
but not here
./retuneTest 1728 1428
Unfortunately the retuning I need is of the first kind...
On Wed, Oct 7, 2015 at 11:17 PM, Dario Fertonani <dario.fertonani at gmail.com>
> Findings below are for B210, UHD 3.9.1, Ubuntu 14.04.3, x86 CPUs.
> All machines show the same problem (Broadwell NUC, Haswell PC).
> In my LTE app, which needs to retune rx frequency every few tens of
> seconds, the retuning time slowly increases, to the point where it is too
> slow (after several hours).
> I was able to replicate this behavior in a toy test (attached), so that
> the problem is seen over a few minutes instead of several hours. The
> retuning time explodes pretty quickly (figure attached). Also, the CPU
> usage does the same, which is not expected, especially in this toy test
> that does nothing but retuning (not even streaming).
> For those interested in replicating the problem, the attached code is
> compiled with
> g++ retuneTest.cpp -o retuneTest -std=c++11 -O3 -luhd
> and run with
> ./retuneTest 1728 739 > /dev/null 2> retuneTest.log
> to store results to file retuneTest.log. The following octave line may be
> used to plot:
> x = load( 'retuneTest.log' ); plot( cumsum( x( : , 3 ) )*1e-3 , x( : , 3 )
> , 'LineWidth' , 2 ); grid on; ylabel( 'Retuning time [ms]' ); xlabel(
> 'Board time [s]' );
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users