Hi Dario,

 My original run was based on our UHD 3.9.1 development branch.  I
 re-ran using the same version you tested
 (UHD_003.008.005-10-g3dbced2d) and observed that the initial
 tuning took 477 milliseconds and retuning took ~400 microseconds.
 My set up is a Lenovo T430s laptop running Ubuntu 14.04.  Perhaps
 running perf to profile the system while running the code will
 help you narrow down the issue on your system.  Also, have you
 tried using USB 2.0 to see if there is a difference?  Some USB 3.0
 controllers are known to have issues.

 Regards,
 Michael

 On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani
 <dario.fertonani@gmail.com <mailto:dario.fertonani@gmail.com>> wrote:

     Thank you Micheal.
     I ran your code and found the same values (400 ms or more) as
     my code. Which is good news because:

      1. It rules out the measurement error (boost vs std::chrono,
         both of which I trust from past experiences).
      2. It points out that the problem is somewhere in my setup,
         since I get much higher values than you do. I ran my code
         on two identical setups, both with B210 and Ubuntu 14.04
         low latency running on Haswell 4 GHz CPUs. I reverted back
         to UHD_003.008.005-10-g3dbced2d since the latest version
         created problems discussed in a different thread.

     Any suggestion on what to check? Or, any chance anybody else
     can run the code to see if this is really a unique problem of
     my setup?

     Thanks,
     Dario



     On Thu, Sep 10, 2015 at 7:30 PM, Michael West
     <michael.west@ettus.com <mailto:michael.west@ettus.com>> wrote:

         Hi Dario,

         I took your code and replaced the std::chrono and
         std::thread stuff with boost equivalents and was able to
         achieve retuning times of ~150-200 microseconds after the
         initial tune (which took ~220 ms).  No appreciable
         difference over USB 2.0 or 3.0. The modified code is attached.

         Regards,
         Michael

         On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via
         USRP-users <usrp-users@lists.ettus.com
         <mailto:usrp-users@lists.ettus.com>> wrote:

             The attached example gives me retuning times of 400 ms
             or more, which is order of magnitudes beyond what is
             expected. Am I calling the API in some suboptimal way?
             I cleaned up the code so that it does nothing but
             retuning between two frequencies. Interestingly, the
             retuning time doesn't vary much with the frequency
             separation.

             Thanks,
             Dario


             On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech
             <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote:

                 On 08/06/2015 09:32 PM, Dario Fertonani wrote:

                 Thank you both for your answers. Anything above a
                 few ms forces me to cross off one of the two
                 design routes I had in mind, so " several 10s of
                 milliseconds" leaves me with a clean path.
                 About the frequency separation of the retuning,
                 it could be up to one GHz.

                 Thanks,
                 Dario

                 I think the current code does "recal avoidance" if
                 the re-tune is less than 100MHz.

                 On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via
                 USRP-users <usrp-users@lists.ettus.com
                 <mailto:usrp-users@lists.ettus.com>> wrote:


                     On Aug 6, 2015, at 4:00 PM, Marcus D. Leech
                     via USRP-users <usrp-users@lists.ettus.com
                     <mailto:usrp-users@lists.ettus.com>> wrote:

                     On 08/03/2015 12:54 AM, Dario Fertonani via
                     USRP-users wrote:

                     Currently my application runs continuous tx
                     and rx on two different frequencies, with
                     B210 in full-duplex MIMO configuration.
                     Let's call fA the tx freq and fB the rx freq.

                     Now I need to read short rx burts at
                     frequency fC (which is far from both fA and
                     fB). Namely, I need to retune the rx stream
                     to fC, receive samples there for a little,
                     then retune back to fB and stay there for a
                     long time. This goes on periodically, while
                     the tx stream stays on fA for the whole time.

                     The following questions are critical for
                     the design of the architecture.

                      1. Can I assume that the rx retuning
                         operations do not affect the tx stream
                         on fA? I have a continuous stream there.
                      2. What is a ballpark value for the
                         retuning time? I'm looking for the time
                         after which retuning is done AND
                         everything is settled, so that the
                         samples streamed from the new frequency
                         are clean.

                     Thanks,
                     Dario

                     The TX and RX synthesizers on the AD9361 and
                     the DSP chains in each direction are
                     independent. Changing parameters of the RX
                     stream will not affect
                       the TX stream.

                     For (2), the AD9361 is not the
                     fastest-locking synthesizer in the world.
                     There's not only the lock-time, but also a
                     *lot* of internal recalibration knobs that
                     have to be adjusted every time it's tuned.
                     Ballpark would be several 10s of milliseconds.

                     Just to add a little more to Marcus's reply.
                     The distance you retune (in Hertz) affects
                     the settling time. Certain re-calibrations
                     are triggered when this exceeds a threshold.
                     How far is "far"?


                     _______________________________________________
                     USRP-users mailing list
                     USRP-users@lists.ettus.com
                     <mailto:USRP-users@lists.ettus.com>
                     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

             _______________________________________________
             USRP-users mailing list
             USRP-users@lists.ettus.com
             <mailto:USRP-users@lists.ettus.com>
             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

On 09/11/2015 02:37 PM, Dario Fertonani wrote: > I tried USB 2.0 and the results are almost identical. > > In summary, retuning takes 450 ms in my system, every time. Michael > gets similar values in the first tuning, but after that there are sub > ms values. My app can live with a few tens of ms for retuning (100x > compared to Michael's results), but 450 ms is too much. > > The app performs well without retuning, reliably streaming 2x2 MIMO > full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB > driver, or UHD version. > > At this point I'm lost. Any suggestion is appreciated. > > Thanks, > Dario > Are you running with external clocking? Is your process running with real-time scheduling, or ordinary scheduling? You mentioned you're using the "low-latency" kernel, what happens if you use a regular kernel? How much memory does your system have, is it paging at all? > > > > On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com > <mailto:michael.west@ettus.com>> wrote: > > Hi Dario, > > My original run was based on our UHD 3.9.1 development branch. I > re-ran using the same version you tested > (UHD_003.008.005-10-g3dbced2d) and observed that the initial > tuning took 477 milliseconds and retuning took ~400 microseconds. > My set up is a Lenovo T430s laptop running Ubuntu 14.04. Perhaps > running perf to profile the system while running the code will > help you narrow down the issue on your system. Also, have you > tried using USB 2.0 to see if there is a difference? Some USB 3.0 > controllers are known to have issues. > > Regards, > Michael > > On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani > <dario.fertonani@gmail.com <mailto:dario.fertonani@gmail.com>> wrote: > > Thank you Micheal. > I ran your code and found the same values (400 ms or more) as > my code. Which is good news because: > > 1. It rules out the measurement error (boost vs std::chrono, > both of which I trust from past experiences). > 2. It points out that the problem is somewhere in my setup, > since I get much higher values than you do. I ran my code > on two identical setups, both with B210 and Ubuntu 14.04 > low latency running on Haswell 4 GHz CPUs. I reverted back > to UHD_003.008.005-10-g3dbced2d since the latest version > created problems discussed in a different thread. > > Any suggestion on what to check? Or, any chance anybody else > can run the code to see if this is really a unique problem of > my setup? > > Thanks, > Dario > > > > On Thu, Sep 10, 2015 at 7:30 PM, Michael West > <michael.west@ettus.com <mailto:michael.west@ettus.com>> wrote: > > Hi Dario, > > I took your code and replaced the std::chrono and > std::thread stuff with boost equivalents and was able to > achieve retuning times of ~150-200 microseconds after the > initial tune (which took ~220 ms). No appreciable > difference over USB 2.0 or 3.0. The modified code is attached. > > Regards, > Michael > > On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via > USRP-users <usrp-users@lists.ettus.com > <mailto:usrp-users@lists.ettus.com>> wrote: > > The attached example gives me retuning times of 400 ms > or more, which is order of magnitudes beyond what is > expected. Am I calling the API in some suboptimal way? > I cleaned up the code so that it does nothing but > retuning between two frequencies. Interestingly, the > retuning time doesn't vary much with the frequency > separation. > > Thanks, > Dario > > > On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech > <mleech@ripnet.com <mailto:mleech@ripnet.com>> wrote: > > On 08/06/2015 09:32 PM, Dario Fertonani wrote: >> Thank you both for your answers. Anything above a >> few ms forces me to cross off one of the two >> design routes I had in mind, so " several 10s of >> milliseconds" leaves me with a clean path. >> About the frequency separation of the retuning, >> it could be up to one GHz. >> >> Thanks, >> Dario > I think the current code does "recal avoidance" if > the re-tune is less than 100MHz. > >> >> >> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via >> USRP-users <usrp-users@lists.ettus.com >> <mailto:usrp-users@lists.ettus.com>> wrote: >> >> >> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech >> via USRP-users <usrp-users@lists.ettus.com >> <mailto:usrp-users@lists.ettus.com>> wrote: >> >>> On 08/03/2015 12:54 AM, Dario Fertonani via >>> USRP-users wrote: >>>> Currently my application runs continuous tx >>>> and rx on two different frequencies, with >>>> B210 in full-duplex MIMO configuration. >>>> Let's call fA the tx freq and fB the rx freq. >>>> >>>> Now I need to read short rx burts at >>>> frequency fC (which is far from both fA and >>>> fB). Namely, I need to retune the rx stream >>>> to fC, receive samples there for a little, >>>> then retune back to fB and stay there for a >>>> long time. This goes on periodically, while >>>> the tx stream stays on fA for the whole time. >>>> >>>> The following questions are critical for >>>> the design of the architecture. >>>> >>>> 1. Can I assume that the rx retuning >>>> operations do not affect the tx stream >>>> on fA? I have a continuous stream there. >>>> 2. What is a ballpark value for the >>>> retuning time? I'm looking for the time >>>> after which retuning is done AND >>>> everything is settled, so that the >>>> samples streamed from the new frequency >>>> are clean. >>>> >>>> Thanks, >>>> Dario >>>> >>> The TX and RX synthesizers on the AD9361 and >>> the DSP chains in each direction are >>> independent. Changing parameters of the RX >>> stream will not affect >>> the TX stream. >>> >>> For (2), the AD9361 is not the >>> fastest-locking synthesizer in the world. >>> There's not only the lock-time, but also a >>> *lot* of internal recalibration knobs that >>> have to be adjusted every time it's tuned. >>> Ballpark would be several 10s of milliseconds. >>> >>> >> Just to add a little more to Marcus's reply. >> The distance you retune (in Hertz) affects >> the settling time. Certain re-calibrations >> are triggered when this exceeds a threshold. >> How far is "far"? >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > >

1. It rules out the measurement error (boost vs std::chrono, both of
which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since I
get much higher values than you do. I ran my code on two identical setups,
both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs.
I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version
created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect
the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking
for the time after which retuning is done AND everything is settled, so
that the samples streamed from the new frequency are clean.

Hi Dario, Try to run perf to profile the system while running the application. It should give you an indication on where the CPU time is being spent. Also, just to clarify, I changed the units from milliseconds to microseconds in the code I modified and I want to make sure you were not misinterpreting the results. Can you send me the actual output from running that code for my own sanity? Thanks, Michael On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> wrote: > On 09/11/2015 02:37 PM, Dario Fertonani wrote: > > I tried USB 2.0 and the results are almost identical. > > In summary, retuning takes 450 ms in my system, every time. Michael gets > similar values in the first tuning, but after that there are sub ms values. > My app can live with a few tens of ms for retuning (100x compared to > Michael's results), but 450 ms is too much. > > The app performs well without retuning, reliably streaming 2x2 MIMO full > duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB driver, > or UHD version. > > At this point I'm lost. Any suggestion is appreciated. > > Thanks, > Dario > > Are you running with external clocking? > > Is your process running with real-time scheduling, or ordinary > scheduling? You mentioned you're using the "low-latency" kernel, what > happens if > you use a regular kernel? > > How much memory does your system have, is it paging at all? > > > > > > > On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> My original run was based on our UHD 3.9.1 development branch. I re-ran >> using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >> observed that the initial tuning took 477 milliseconds and retuning took >> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >> 14.04. Perhaps running perf to profile the system while running the code >> will help you narrow down the issue on your system. Also, have you tried >> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >> are known to have issues. >> >> Regards, >> Michael >> >> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >> dario.fertonani@gmail.com> wrote: >> >>> Thank you Micheal. >>> I ran your code and found the same values (400 ms or more) as my code. >>> Which is good news because: >>> >>> 1. It rules out the measurement error (boost vs std::chrono, both of >>> which I trust from past experiences). >>> 2. It points out that the problem is somewhere in my setup, since I >>> get much higher values than you do. I ran my code on two identical setups, >>> both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs. >>> I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version >>> created problems discussed in a different thread. >>> >>> Any suggestion on what to check? Or, any chance anybody else can run the >>> code to see if this is really a unique problem of my setup? >>> >>> Thanks, >>> Dario >>> >>> >>> >>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> >>> wrote: >>> >>>> Hi Dario, >>>> >>>> I took your code and replaced the std::chrono and std::thread stuff >>>> with boost equivalents and was able to achieve retuning times of ~150-200 >>>> microseconds after the initial tune (which took ~220 ms). No appreciable >>>> difference over USB 2.0 or 3.0. The modified code is attached. >>>> >>>> Regards, >>>> Michael >>>> >>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> The attached example gives me retuning times of 400 ms or more, which >>>>> is order of magnitudes beyond what is expected. Am I calling the API in >>>>> some suboptimal way? >>>>> I cleaned up the code so that it does nothing but retuning between two >>>>> frequencies. Interestingly, the retuning time doesn't vary much with the >>>>> frequency separation. >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> >>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>>>> wrote: >>>>> >>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>> >>>>>> Thank you both for your answers. Anything above a few ms forces me to >>>>>> cross off one of the two design routes I had in mind, so " several 10s of >>>>>> milliseconds" leaves me with a clean path. >>>>>> About the frequency separation of the retuning, it could be up to one >>>>>> GHz. >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> I think the current code does "recal avoidance" if the re-tune is >>>>>> less than 100MHz. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> >>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>> >>>>>>> Currently my application runs continuous tx and rx on two different >>>>>>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>>>>>> tx freq and fB the rx freq. >>>>>>> >>>>>>> Now I need to read short rx burts at frequency fC (which is far from >>>>>>> both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>> the whole time. >>>>>>> >>>>>>> The following questions are critical for the design of the >>>>>>> architecture. >>>>>>> >>>>>>> 1. Can I assume that the rx retuning operations do not affect >>>>>>> the tx stream on fA? I have a continuous stream there. >>>>>>> 2. What is a ballpark value for the retuning time? I'm looking >>>>>>> for the time after which retuning is done AND everything is settled, so >>>>>>> that the samples streamed from the new frequency are clean. >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>>>>>> direction are independent. Changing parameters of the RX stream will not >>>>>>> affect >>>>>>> the TX stream. >>>>>>> >>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>> >>>>>>> >>>>>>> Just to add a little more to Marcus's reply. The distance you retune >>>>>>> (in Hertz) affects the settling time. Certain re-calibrations are triggered >>>>>>> when this exceeds a threshold. How far is "far"? >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>> >>> >> > >

1. It rules out the measurement error (boost vs std::chrono, both
of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since I
get much higher values than you do. I ran my code on two identical setups,
both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs.
I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version
created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect
the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking
for the time after which retuning is done AND everything is settled, so
that the samples streamed from the new frequency are clean.

Michael, Please find attached the output file you requested. It is the output of the bash line ./retuneTime 739 751 &> ./retuneTime.log after I compiled your code with g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system -lboost_thread You'll notice that the retuning time is indeed above 400 ms, every time. About your profiling suggestion... I'm profiling the time taken to execute set_rx_freq and nothing more. Are you suggesting I profile what UHD actually does within that call? If so, could you please send me a command line with perf usage? Marcus, I'm running internal clock and real-time scheduling. I installed the regular kernel (as opposed to the low-latency kernel that is my default) and the results are identical. System memory/cache isn't a problem. The code just loops over retuning calls, without streaming anything, so really the system horsepower isn't a problem here. In general, I was hoping there was an API usage problem on my side, which doesn't seem to be the case. This system is good enough to stream and process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it hard to believe that the same system needs 400 ms just to retune. I tried USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and all give the same result. I tried different UHD versions and different CPUs (all Haswell 3.6 GHz or better). Thanks, Dario On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > Try to run perf to profile the system while running the application. It > should give you an indication on where the CPU time is being spent. > > Also, just to clarify, I changed the units from milliseconds to > microseconds in the code I modified and I want to make sure you were not > misinterpreting the results. Can you send me the actual output from > running that code for my own sanity? > > Thanks, > Michael > > On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> > wrote: > >> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >> >> I tried USB 2.0 and the results are almost identical. >> >> In summary, retuning takes 450 ms in my system, every time. Michael gets >> similar values in the first tuning, but after that there are sub ms values. >> My app can live with a few tens of ms for retuning (100x compared to >> Michael's results), but 450 ms is too much. >> >> The app performs well without retuning, reliably streaming 2x2 MIMO full >> duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB driver, >> or UHD version. >> >> At this point I'm lost. Any suggestion is appreciated. >> >> Thanks, >> Dario >> >> Are you running with external clocking? >> >> Is your process running with real-time scheduling, or ordinary >> scheduling? You mentioned you're using the "low-latency" kernel, what >> happens if >> you use a regular kernel? >> >> How much memory does your system have, is it paging at all? >> >> >> >> >> >> >> On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com> >> wrote: >> >>> Hi Dario, >>> >>> My original run was based on our UHD 3.9.1 development branch. I re-ran >>> using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>> observed that the initial tuning took 477 milliseconds and retuning took >>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>> 14.04. Perhaps running perf to profile the system while running the code >>> will help you narrow down the issue on your system. Also, have you tried >>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>> are known to have issues. >>> >>> Regards, >>> Michael >>> >>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>> dario.fertonani@gmail.com> wrote: >>> >>>> Thank you Micheal. >>>> I ran your code and found the same values (400 ms or more) as my code. >>>> Which is good news because: >>>> >>>> 1. It rules out the measurement error (boost vs std::chrono, both >>>> of which I trust from past experiences). >>>> 2. It points out that the problem is somewhere in my setup, since I >>>> get much higher values than you do. I ran my code on two identical setups, >>>> both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs. >>>> I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version >>>> created problems discussed in a different thread. >>>> >>>> Any suggestion on what to check? Or, any chance anybody else can run >>>> the code to see if this is really a unique problem of my setup? >>>> >>>> Thanks, >>>> Dario >>>> >>>> >>>> >>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> >>>> wrote: >>>> >>>>> Hi Dario, >>>>> >>>>> I took your code and replaced the std::chrono and std::thread stuff >>>>> with boost equivalents and was able to achieve retuning times of ~150-200 >>>>> microseconds after the initial tune (which took ~220 ms). No appreciable >>>>> difference over USB 2.0 or 3.0. The modified code is attached. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> The attached example gives me retuning times of 400 ms or more, which >>>>>> is order of magnitudes beyond what is expected. Am I calling the API in >>>>>> some suboptimal way? >>>>>> I cleaned up the code so that it does nothing but retuning between >>>>>> two frequencies. Interestingly, the retuning time doesn't vary much with >>>>>> the frequency separation. >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>>>>> wrote: >>>>>> >>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>> >>>>>>> Thank you both for your answers. Anything above a few ms forces me >>>>>>> to cross off one of the two design routes I had in mind, so " several 10s >>>>>>> of milliseconds" leaves me with a clean path. >>>>>>> About the frequency separation of the retuning, it could be up to >>>>>>> one GHz. >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> I think the current code does "recal avoidance" if the re-tune is >>>>>>> less than 100MHz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>> >>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>> >>>>>>>> Currently my application runs continuous tx and rx on two different >>>>>>>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>>>>>>> tx freq and fB the rx freq. >>>>>>>> >>>>>>>> Now I need to read short rx burts at frequency fC (which is far >>>>>>>> from both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>>> the whole time. >>>>>>>> >>>>>>>> The following questions are critical for the design of the >>>>>>>> architecture. >>>>>>>> >>>>>>>> 1. Can I assume that the rx retuning operations do not affect >>>>>>>> the tx stream on fA? I have a continuous stream there. >>>>>>>> 2. What is a ballpark value for the retuning time? I'm looking >>>>>>>> for the time after which retuning is done AND everything is settled, so >>>>>>>> that the samples streamed from the new frequency are clean. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dario >>>>>>>> >>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>>>>>>> direction are independent. Changing parameters of the RX stream will not >>>>>>>> affect >>>>>>>> the TX stream. >>>>>>>> >>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>> >>>>>>>> >>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> USRP-users@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> USRP-users@lists.ettus.com >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>> >>>>>> >>>>> >>>> >>> >> >> >

1. It rules out the measurement error (boost vs std::chrono, both
of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since
I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect
the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking
for the time after which retuning is done AND everything is settled, so
that the samples streamed from the new frequency are clean.

Hi Dario, It is not your set up. I have reproduced the problem. Sadly, I put in the wrong parameters during my first tests, so it was not actually retuning. I will dig into the issue and let you know what I find. Regards, Michael On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani <dario.fertonani@gmail.com> wrote: > Michael, > Please find attached the output file you requested. > It is the output of the bash line > > ./retuneTime 739 751 &> ./retuneTime.log > > after I compiled your code with > > g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system > -lboost_thread > > You'll notice that the retuning time is indeed above 400 ms, every time. > About your profiling suggestion... I'm profiling the time taken to execute > > set_rx_freq > > and nothing more. Are you suggesting I profile what UHD actually does > within that call? If so, could you please send me a command line with perf > usage? > > Marcus, > I'm running internal clock and real-time scheduling. I installed the > regular kernel (as opposed to the low-latency kernel that is my default) > and the results are identical. System memory/cache isn't a problem. The > code just loops over retuning calls, without streaming anything, so really > the system horsepower isn't a problem here. > > In general, I was hoping there was an API usage problem on my side, which > doesn't seem to be the case. This system is good enough to stream and > process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it > hard to believe that the same system needs 400 ms just to retune. I tried > USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and > all give the same result. I tried different UHD versions and different CPUs > (all Haswell 3.6 GHz or better). > > Thanks, > Dario > > > > On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> Try to run perf to profile the system while running the application. It >> should give you an indication on where the CPU time is being spent. >> >> Also, just to clarify, I changed the units from milliseconds to >> microseconds in the code I modified and I want to make sure you were not >> misinterpreting the results. Can you send me the actual output from >> running that code for my own sanity? >> >> Thanks, >> Michael >> >> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> >> wrote: >> >>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>> >>> I tried USB 2.0 and the results are almost identical. >>> >>> In summary, retuning takes 450 ms in my system, every time. Michael gets >>> similar values in the first tuning, but after that there are sub ms values. >>> My app can live with a few tens of ms for retuning (100x compared to >>> Michael's results), but 450 ms is too much. >>> >>> The app performs well without retuning, reliably streaming 2x2 MIMO full >>> duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB driver, >>> or UHD version. >>> >>> At this point I'm lost. Any suggestion is appreciated. >>> >>> Thanks, >>> Dario >>> >>> Are you running with external clocking? >>> >>> Is your process running with real-time scheduling, or ordinary >>> scheduling? You mentioned you're using the "low-latency" kernel, what >>> happens if >>> you use a regular kernel? >>> >>> How much memory does your system have, is it paging at all? >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com> >>> wrote: >>> >>>> Hi Dario, >>>> >>>> My original run was based on our UHD 3.9.1 development branch. I >>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>> observed that the initial tuning took 477 milliseconds and retuning took >>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>> 14.04. Perhaps running perf to profile the system while running the code >>>> will help you narrow down the issue on your system. Also, have you tried >>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>> are known to have issues. >>>> >>>> Regards, >>>> Michael >>>> >>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>> dario.fertonani@gmail.com> wrote: >>>> >>>>> Thank you Micheal. >>>>> I ran your code and found the same values (400 ms or more) as my code. >>>>> Which is good news because: >>>>> >>>>> 1. It rules out the measurement error (boost vs std::chrono, both >>>>> of which I trust from past experiences). >>>>> 2. It points out that the problem is somewhere in my setup, since >>>>> I get much higher values than you do. I ran my code on two identical >>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>> version created problems discussed in a different thread. >>>>> >>>>> Any suggestion on what to check? Or, any chance anybody else can run >>>>> the code to see if this is really a unique problem of my setup? >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> >>>>> >>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> >>>>> wrote: >>>>> >>>>>> Hi Dario, >>>>>> >>>>>> I took your code and replaced the std::chrono and std::thread stuff >>>>>> with boost equivalents and was able to achieve retuning times of ~150-200 >>>>>> microseconds after the initial tune (which took ~220 ms). No appreciable >>>>>> difference over USB 2.0 or 3.0. The modified code is attached. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>> in some suboptimal way? >>>>>>> I cleaned up the code so that it does nothing but retuning between >>>>>>> two frequencies. Interestingly, the retuning time doesn't vary much with >>>>>>> the frequency separation. >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>> >>>>>>>> Thank you both for your answers. Anything above a few ms forces me >>>>>>>> to cross off one of the two design routes I had in mind, so " several 10s >>>>>>>> of milliseconds" leaves me with a clean path. >>>>>>>> About the frequency separation of the retuning, it could be up to >>>>>>>> one GHz. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dario >>>>>>>> >>>>>>>> I think the current code does "recal avoidance" if the re-tune is >>>>>>>> less than 100MHz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>> >>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>> >>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>> >>>>>>>>> Now I need to read short rx burts at frequency fC (which is far >>>>>>>>> from both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>>>> the whole time. >>>>>>>>> >>>>>>>>> The following questions are critical for the design of the >>>>>>>>> architecture. >>>>>>>>> >>>>>>>>> 1. Can I assume that the rx retuning operations do not affect >>>>>>>>> the tx stream on fA? I have a continuous stream there. >>>>>>>>> 2. What is a ballpark value for the retuning time? I'm looking >>>>>>>>> for the time after which retuning is done AND everything is settled, so >>>>>>>>> that the samples streamed from the new frequency are clean. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in >>>>>>>>> each direction are independent. Changing parameters of the RX stream will >>>>>>>>> not affect >>>>>>>>> the TX stream. >>>>>>>>> >>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>>>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>> >>>>>>>>> >>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono, both
of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since
I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect
the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Thank you Micheal. Please keep me updated on the progress. Is it safe to assume that this is an UHD bug, or should I start thinking about a system design that doesn't rely on returning time faster than 400 ms? Thanks, Dario On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > It is not your set up. I have reproduced the problem. Sadly, I put in > the wrong parameters during my first tests, so it was not actually > retuning. I will dig into the issue and let you know what I find. > > Regards, > Michael > > On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < > dario.fertonani@gmail.com> wrote: > >> Michael, >> Please find attached the output file you requested. >> It is the output of the bash line >> >> ./retuneTime 739 751 &> ./retuneTime.log >> >> after I compiled your code with >> >> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >> -lboost_thread >> >> You'll notice that the retuning time is indeed above 400 ms, every time. >> About your profiling suggestion... I'm profiling the time taken to execute >> >> set_rx_freq >> >> and nothing more. Are you suggesting I profile what UHD actually does >> within that call? If so, could you please send me a command line with perf >> usage? >> >> Marcus, >> I'm running internal clock and real-time scheduling. I installed the >> regular kernel (as opposed to the low-latency kernel that is my default) >> and the results are identical. System memory/cache isn't a problem. The >> code just loops over retuning calls, without streaming anything, so really >> the system horsepower isn't a problem here. >> >> In general, I was hoping there was an API usage problem on my side, which >> doesn't seem to be the case. This system is good enough to stream and >> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >> hard to believe that the same system needs 400 ms just to retune. I tried >> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >> all give the same result. I tried different UHD versions and different CPUs >> (all Haswell 3.6 GHz or better). >> >> Thanks, >> Dario >> >> >> >> On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com> >> wrote: >> >>> Hi Dario, >>> >>> Try to run perf to profile the system while running the application. It >>> should give you an indication on where the CPU time is being spent. >>> >>> Also, just to clarify, I changed the units from milliseconds to >>> microseconds in the code I modified and I want to make sure you were not >>> misinterpreting the results. Can you send me the actual output from >>> running that code for my own sanity? >>> >>> Thanks, >>> Michael >>> >>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> >>> wrote: >>> >>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>> >>>> I tried USB 2.0 and the results are almost identical. >>>> >>>> In summary, retuning takes 450 ms in my system, every time. Michael >>>> gets similar values in the first tuning, but after that there are sub ms >>>> values. My app can live with a few tens of ms for retuning (100x compared >>>> to Michael's results), but 450 ms is too much. >>>> >>>> The app performs well without retuning, reliably streaming 2x2 MIMO >>>> full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>> driver, or UHD version. >>>> >>>> At this point I'm lost. Any suggestion is appreciated. >>>> >>>> Thanks, >>>> Dario >>>> >>>> Are you running with external clocking? >>>> >>>> Is your process running with real-time scheduling, or ordinary >>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>> happens if >>>> you use a regular kernel? >>>> >>>> How much memory does your system have, is it paging at all? >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com> >>>> wrote: >>>> >>>>> Hi Dario, >>>>> >>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>> will help you narrow down the issue on your system. Also, have you tried >>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>> are known to have issues. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>> dario.fertonani@gmail.com> wrote: >>>>> >>>>>> Thank you Micheal. >>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>> code. Which is good news because: >>>>>> >>>>>> 1. It rules out the measurement error (boost vs std::chrono, both >>>>>> of which I trust from past experiences). >>>>>> 2. It points out that the problem is somewhere in my setup, since >>>>>> I get much higher values than you do. I ran my code on two identical >>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>> version created problems discussed in a different thread. >>>>>> >>>>>> Any suggestion on what to check? Or, any chance anybody else can run >>>>>> the code to see if this is really a unique problem of my setup? >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com >>>>>> > wrote: >>>>>> >>>>>>> Hi Dario, >>>>>>> >>>>>>> I took your code and replaced the std::chrono and std::thread stuff >>>>>>> with boost equivalents and was able to achieve retuning times of ~150-200 >>>>>>> microseconds after the initial tune (which took ~220 ms). No appreciable >>>>>>> difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>>> in some suboptimal way? >>>>>>>> I cleaned up the code so that it does nothing but retuning between >>>>>>>> two frequencies. Interestingly, the retuning time doesn't vary much with >>>>>>>> the frequency separation. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dario >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>> >>>>>>>>> Thank you both for your answers. Anything above a few ms forces me >>>>>>>>> to cross off one of the two design routes I had in mind, so " several 10s >>>>>>>>> of milliseconds" leaves me with a clean path. >>>>>>>>> About the frequency separation of the retuning, it could be up to >>>>>>>>> one GHz. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> I think the current code does "recal avoidance" if the re-tune is >>>>>>>>> less than 100MHz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>> >>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>> >>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>> >>>>>>>>>> Now I need to read short rx burts at frequency fC (which is far >>>>>>>>>> from both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>>>>> the whole time. >>>>>>>>>> >>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>> architecture. >>>>>>>>>> >>>>>>>>>> 1. Can I assume that the rx retuning operations do not affect >>>>>>>>>> the tx stream on fA? I have a continuous stream there. >>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dario >>>>>>>>>> >>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in >>>>>>>>>> each direction are independent. Changing parameters of the RX stream will >>>>>>>>>> not affect >>>>>>>>>> the TX stream. >>>>>>>>>> >>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>>>>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> USRP-users@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono,
both of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup,
since I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not
affect the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Hi Dario, I am treating it as a UHD bug for now. Tuning times should be less than 400 ms. My testing so far has shown that the quadrature calibration is taking most of the time. Skipping quadrature calibration reduces the tuning time to only ~3.3 ms. I found another inefficiency in the tuning algorithm that further reduced it down to ~1.5 ms. So there is hope. What retuning range does your application require? Regards, Michael On Fri, Sep 11, 2015 at 5:09 PM, Dario Fertonani <dario.fertonani@gmail.com> wrote: > Thank you Micheal. Please keep me updated on the progress. > Is it safe to assume that this is an UHD bug, or should I start thinking > about a system design that doesn't rely on returning time faster than 400 > ms? > > Thanks, > Dario > > > On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> It is not your set up. I have reproduced the problem. Sadly, I put in >> the wrong parameters during my first tests, so it was not actually >> retuning. I will dig into the issue and let you know what I find. >> >> Regards, >> Michael >> >> On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < >> dario.fertonani@gmail.com> wrote: >> >>> Michael, >>> Please find attached the output file you requested. >>> It is the output of the bash line >>> >>> ./retuneTime 739 751 &> ./retuneTime.log >>> >>> after I compiled your code with >>> >>> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >>> -lboost_thread >>> >>> You'll notice that the retuning time is indeed above 400 ms, every time. >>> About your profiling suggestion... I'm profiling the time taken to >>> execute >>> >>> set_rx_freq >>> >>> and nothing more. Are you suggesting I profile what UHD actually does >>> within that call? If so, could you please send me a command line with perf >>> usage? >>> >>> Marcus, >>> I'm running internal clock and real-time scheduling. I installed the >>> regular kernel (as opposed to the low-latency kernel that is my default) >>> and the results are identical. System memory/cache isn't a problem. The >>> code just loops over retuning calls, without streaming anything, so really >>> the system horsepower isn't a problem here. >>> >>> In general, I was hoping there was an API usage problem on my side, >>> which doesn't seem to be the case. This system is good enough to stream and >>> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >>> hard to believe that the same system needs 400 ms just to retune. I tried >>> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >>> all give the same result. I tried different UHD versions and different CPUs >>> (all Haswell 3.6 GHz or better). >>> >>> Thanks, >>> Dario >>> >>> >>> >>> On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com> >>> wrote: >>> >>>> Hi Dario, >>>> >>>> Try to run perf to profile the system while running the application. >>>> It should give you an indication on where the CPU time is being spent. >>>> >>>> Also, just to clarify, I changed the units from milliseconds to >>>> microseconds in the code I modified and I want to make sure you were not >>>> misinterpreting the results. Can you send me the actual output from >>>> running that code for my own sanity? >>>> >>>> Thanks, >>>> Michael >>>> >>>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> >>>> wrote: >>>> >>>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>>> >>>>> I tried USB 2.0 and the results are almost identical. >>>>> >>>>> In summary, retuning takes 450 ms in my system, every time. Michael >>>>> gets similar values in the first tuning, but after that there are sub ms >>>>> values. My app can live with a few tens of ms for retuning (100x compared >>>>> to Michael's results), but 450 ms is too much. >>>>> >>>>> The app performs well without retuning, reliably streaming 2x2 MIMO >>>>> full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>>> driver, or UHD version. >>>>> >>>>> At this point I'm lost. Any suggestion is appreciated. >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> Are you running with external clocking? >>>>> >>>>> Is your process running with real-time scheduling, or ordinary >>>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>>> happens if >>>>> you use a regular kernel? >>>>> >>>>> How much memory does your system have, is it paging at all? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com >>>>> > wrote: >>>>> >>>>>> Hi Dario, >>>>>> >>>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>>> will help you narrow down the issue on your system. Also, have you tried >>>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>>> are known to have issues. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>>> dario.fertonani@gmail.com> wrote: >>>>>> >>>>>>> Thank you Micheal. >>>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>>> code. Which is good news because: >>>>>>> >>>>>>> 1. It rules out the measurement error (boost vs std::chrono, >>>>>>> both of which I trust from past experiences). >>>>>>> 2. It points out that the problem is somewhere in my setup, >>>>>>> since I get much higher values than you do. I ran my code on two identical >>>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>>> version created problems discussed in a different thread. >>>>>>> >>>>>>> Any suggestion on what to check? Or, any chance anybody else can run >>>>>>> the code to see if this is really a unique problem of my setup? >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West < >>>>>>> michael.west@ettus.com> wrote: >>>>>>> >>>>>>>> Hi Dario, >>>>>>>> >>>>>>>> I took your code and replaced the std::chrono and std::thread stuff >>>>>>>> with boost equivalents and was able to achieve retuning times of ~150-200 >>>>>>>> microseconds after the initial tune (which took ~220 ms). No appreciable >>>>>>>> difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Michael >>>>>>>> >>>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>> >>>>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>>>> in some suboptimal way? >>>>>>>>> I cleaned up the code so that it does nothing but retuning between >>>>>>>>> two frequencies. Interestingly, the retuning time doesn't vary much with >>>>>>>>> the frequency separation. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>>> >>>>>>>>>> Thank you both for your answers. Anything above a few ms forces >>>>>>>>>> me to cross off one of the two design routes I had in mind, so " several >>>>>>>>>> 10s of milliseconds" leaves me with a clean path. >>>>>>>>>> About the frequency separation of the retuning, it could be up to >>>>>>>>>> one GHz. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dario >>>>>>>>>> >>>>>>>>>> I think the current code does "recal avoidance" if the re-tune is >>>>>>>>>> less than 100MHz. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>>> >>>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>>> >>>>>>>>>>> Now I need to read short rx burts at frequency fC (which is far >>>>>>>>>>> from both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>>>>>> the whole time. >>>>>>>>>>> >>>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>>> architecture. >>>>>>>>>>> >>>>>>>>>>> 1. Can I assume that the rx retuning operations do not >>>>>>>>>>> affect the tx stream on fA? I have a continuous stream there. >>>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dario >>>>>>>>>>> >>>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in >>>>>>>>>>> each direction are independent. Changing parameters of the RX stream will >>>>>>>>>>> not affect >>>>>>>>>>> the TX stream. >>>>>>>>>>> >>>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in >>>>>>>>>>> the world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> USRP-users mailing list >>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>> >>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono,
both of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup,
since I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not
affect the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Michael, That's great news! Anything below 50 ms would work in my design. Also, sorry for misspelling your name earlier. Best, Dario On Fri, Sep 11, 2015 at 5:27 PM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > I am treating it as a UHD bug for now. Tuning times should be less than > 400 ms. My testing so far has shown that the quadrature calibration is > taking most of the time. Skipping quadrature calibration reduces the > tuning time to only ~3.3 ms. I found another inefficiency in the tuning > algorithm that further reduced it down to ~1.5 ms. So there is hope. What > retuning range does your application require? > > Regards, > Michael > > On Fri, Sep 11, 2015 at 5:09 PM, Dario Fertonani < > dario.fertonani@gmail.com> wrote: > >> Thank you Micheal. Please keep me updated on the progress. >> Is it safe to assume that this is an UHD bug, or should I start thinking >> about a system design that doesn't rely on returning time faster than 400 >> ms? >> >> Thanks, >> Dario >> >> >> On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> >> wrote: >> >>> Hi Dario, >>> >>> It is not your set up. I have reproduced the problem. Sadly, I put in >>> the wrong parameters during my first tests, so it was not actually >>> retuning. I will dig into the issue and let you know what I find. >>> >>> Regards, >>> Michael >>> >>> On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < >>> dario.fertonani@gmail.com> wrote: >>> >>>> Michael, >>>> Please find attached the output file you requested. >>>> It is the output of the bash line >>>> >>>> ./retuneTime 739 751 &> ./retuneTime.log >>>> >>>> after I compiled your code with >>>> >>>> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >>>> -lboost_thread >>>> >>>> You'll notice that the retuning time is indeed above 400 ms, every time. >>>> About your profiling suggestion... I'm profiling the time taken to >>>> execute >>>> >>>> set_rx_freq >>>> >>>> and nothing more. Are you suggesting I profile what UHD actually does >>>> within that call? If so, could you please send me a command line with perf >>>> usage? >>>> >>>> Marcus, >>>> I'm running internal clock and real-time scheduling. I installed the >>>> regular kernel (as opposed to the low-latency kernel that is my default) >>>> and the results are identical. System memory/cache isn't a problem. The >>>> code just loops over retuning calls, without streaming anything, so really >>>> the system horsepower isn't a problem here. >>>> >>>> In general, I was hoping there was an API usage problem on my side, >>>> which doesn't seem to be the case. This system is good enough to stream and >>>> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >>>> hard to believe that the same system needs 400 ms just to retune. I tried >>>> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >>>> all give the same result. I tried different UHD versions and different CPUs >>>> (all Haswell 3.6 GHz or better). >>>> >>>> Thanks, >>>> Dario >>>> >>>> >>>> >>>> On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com> >>>> wrote: >>>> >>>>> Hi Dario, >>>>> >>>>> Try to run perf to profile the system while running the application. >>>>> It should give you an indication on where the CPU time is being spent. >>>>> >>>>> Also, just to clarify, I changed the units from milliseconds to >>>>> microseconds in the code I modified and I want to make sure you were not >>>>> misinterpreting the results. Can you send me the actual output from >>>>> running that code for my own sanity? >>>>> >>>>> Thanks, >>>>> Michael >>>>> >>>>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> >>>>> wrote: >>>>> >>>>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>>>> >>>>>> I tried USB 2.0 and the results are almost identical. >>>>>> >>>>>> In summary, retuning takes 450 ms in my system, every time. Michael >>>>>> gets similar values in the first tuning, but after that there are sub ms >>>>>> values. My app can live with a few tens of ms for retuning (100x compared >>>>>> to Michael's results), but 450 ms is too much. >>>>>> >>>>>> The app performs well without retuning, reliably streaming 2x2 MIMO >>>>>> full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>>>> driver, or UHD version. >>>>>> >>>>>> At this point I'm lost. Any suggestion is appreciated. >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> Are you running with external clocking? >>>>>> >>>>>> Is your process running with real-time scheduling, or ordinary >>>>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>>>> happens if >>>>>> you use a regular kernel? >>>>>> >>>>>> How much memory does your system have, is it paging at all? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West < >>>>>> michael.west@ettus.com> wrote: >>>>>> >>>>>>> Hi Dario, >>>>>>> >>>>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>>>> will help you narrow down the issue on your system. Also, have you tried >>>>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>>>> are known to have issues. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>>>> dario.fertonani@gmail.com> wrote: >>>>>>> >>>>>>>> Thank you Micheal. >>>>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>>>> code. Which is good news because: >>>>>>>> >>>>>>>> 1. It rules out the measurement error (boost vs std::chrono, >>>>>>>> both of which I trust from past experiences). >>>>>>>> 2. It points out that the problem is somewhere in my setup, >>>>>>>> since I get much higher values than you do. I ran my code on two identical >>>>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>>>> version created problems discussed in a different thread. >>>>>>>> >>>>>>>> Any suggestion on what to check? Or, any chance anybody else can >>>>>>>> run the code to see if this is really a unique problem of my setup? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dario >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West < >>>>>>>> michael.west@ettus.com> wrote: >>>>>>>> >>>>>>>>> Hi Dario, >>>>>>>>> >>>>>>>>> I took your code and replaced the std::chrono and std::thread >>>>>>>>> stuff with boost equivalents and was able to achieve retuning times of >>>>>>>>> ~150-200 microseconds after the initial tune (which took ~220 ms). No >>>>>>>>> appreciable difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>> >>>>>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>>>>> in some suboptimal way? >>>>>>>>>> I cleaned up the code so that it does nothing but retuning >>>>>>>>>> between two frequencies. Interestingly, the retuning time doesn't vary much >>>>>>>>>> with the frequency separation. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dario >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech < >>>>>>>>>> mleech@ripnet.com> wrote: >>>>>>>>>> >>>>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>>>> >>>>>>>>>>> Thank you both for your answers. Anything above a few ms forces >>>>>>>>>>> me to cross off one of the two design routes I had in mind, so " several >>>>>>>>>>> 10s of milliseconds" leaves me with a clean path. >>>>>>>>>>> About the frequency separation of the retuning, it could be up >>>>>>>>>>> to one GHz. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dario >>>>>>>>>>> >>>>>>>>>>> I think the current code does "recal avoidance" if the re-tune >>>>>>>>>>> is less than 100MHz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>>>> >>>>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>>>> >>>>>>>>>>>> Now I need to read short rx burts at frequency fC (which is far >>>>>>>>>>>> from both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>>>>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>>>>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>>>>>>>> the whole time. >>>>>>>>>>>> >>>>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>>>> architecture. >>>>>>>>>>>> >>>>>>>>>>>> 1. Can I assume that the rx retuning operations do not >>>>>>>>>>>> affect the tx stream on fA? I have a continuous stream there. >>>>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dario >>>>>>>>>>>> >>>>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in >>>>>>>>>>>> each direction are independent. Changing parameters of the RX stream will >>>>>>>>>>>> not affect >>>>>>>>>>>> the TX stream. >>>>>>>>>>>> >>>>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in >>>>>>>>>>>> the world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono,
both of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup,
since I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not
affect the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Hi Dario, Attached is a patch (made for UHD_003.008.005-0-g7efbd15b) that reduces the retuning time significantly. The retune time is dependent on how far you tune. Within 100 MHz and the retune time is ~1.5 ms. Beyond 100 MHz, it is ~170 ms due to the DC offset calibration. Some of the changes in the patch were pulled from the UHD 3.9.1 development code base and some I manually made. It is possible to extend the range beyond 100 MHz, but the DC offset and IQ imbalance will get worse the larger the range is made. I also tested the code in the UHD 3.9.1 development code base and the retune times were ~3.3 ms within 100 MHz and ~205 ms beyond 100 MHz, so much of what is in the patch has already been put into UHD and will be available in the UHD 3.9.1 release that is coming very soon. If the retune is within a quarter of the master clock rate from the LO frequency, you can improve the tuning time down to a few microseconds by tuning only the DSP frequency. I noticed you were setting the master clock rate to 15.36e6. I would suggest setting the master clock rate to 30.72e6 (or even 61.44e6 if running a single channel). Your sample rate can be lower, but setting the master clock rate higher gives you more room to tune the DSP frequency without changing the LO frequency. At a master clock rate of 30.72, you will have a DSP tuning range of +/-7.68 MHz. If that is sufficient range for your application, you don't need the patch at all. Either change to DSP tuning or give the patch a try and let me know if it works out for you. Regards, Michael On Fri, Sep 11, 2015 at 5:36 PM, Dario Fertonani <dario.fertonani@gmail.com> wrote: > Michael, > > That's great news! Anything below 50 ms would work in my design. > Also, sorry for misspelling your name earlier. > > Best, > Dario > > > > On Fri, Sep 11, 2015 at 5:27 PM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> I am treating it as a UHD bug for now. Tuning times should be less than >> 400 ms. My testing so far has shown that the quadrature calibration is >> taking most of the time. Skipping quadrature calibration reduces the >> tuning time to only ~3.3 ms. I found another inefficiency in the tuning >> algorithm that further reduced it down to ~1.5 ms. So there is hope. What >> retuning range does your application require? >> >> Regards, >> Michael >> >> On Fri, Sep 11, 2015 at 5:09 PM, Dario Fertonani < >> dario.fertonani@gmail.com> wrote: >> >>> Thank you Micheal. Please keep me updated on the progress. >>> Is it safe to assume that this is an UHD bug, or should I start thinking >>> about a system design that doesn't rely on returning time faster than 400 >>> ms? >>> >>> Thanks, >>> Dario >>> >>> >>> On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> >>> wrote: >>> >>>> Hi Dario, >>>> >>>> It is not your set up. I have reproduced the problem. Sadly, I put in >>>> the wrong parameters during my first tests, so it was not actually >>>> retuning. I will dig into the issue and let you know what I find. >>>> >>>> Regards, >>>> Michael >>>> >>>> On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < >>>> dario.fertonani@gmail.com> wrote: >>>> >>>>> Michael, >>>>> Please find attached the output file you requested. >>>>> It is the output of the bash line >>>>> >>>>> ./retuneTime 739 751 &> ./retuneTime.log >>>>> >>>>> after I compiled your code with >>>>> >>>>> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >>>>> -lboost_thread >>>>> >>>>> You'll notice that the retuning time is indeed above 400 ms, every >>>>> time. >>>>> About your profiling suggestion... I'm profiling the time taken to >>>>> execute >>>>> >>>>> set_rx_freq >>>>> >>>>> and nothing more. Are you suggesting I profile what UHD actually does >>>>> within that call? If so, could you please send me a command line with perf >>>>> usage? >>>>> >>>>> Marcus, >>>>> I'm running internal clock and real-time scheduling. I installed the >>>>> regular kernel (as opposed to the low-latency kernel that is my default) >>>>> and the results are identical. System memory/cache isn't a problem. The >>>>> code just loops over retuning calls, without streaming anything, so really >>>>> the system horsepower isn't a problem here. >>>>> >>>>> In general, I was hoping there was an API usage problem on my side, >>>>> which doesn't seem to be the case. This system is good enough to stream and >>>>> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >>>>> hard to believe that the same system needs 400 ms just to retune. I tried >>>>> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >>>>> all give the same result. I tried different UHD versions and different CPUs >>>>> (all Haswell 3.6 GHz or better). >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> >>>>> >>>>> On Fri, Sep 11, 2015 at 12:58 PM, Michael West <michael.west@ettus.com >>>>> > wrote: >>>>> >>>>>> Hi Dario, >>>>>> >>>>>> Try to run perf to profile the system while running the application. >>>>>> It should give you an indication on where the CPU time is being spent. >>>>>> >>>>>> Also, just to clarify, I changed the units from milliseconds to >>>>>> microseconds in the code I modified and I want to make sure you were not >>>>>> misinterpreting the results. Can you send me the actual output from >>>>>> running that code for my own sanity? >>>>>> >>>>>> Thanks, >>>>>> Michael >>>>>> >>>>>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com> >>>>>> wrote: >>>>>> >>>>>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>>>>> >>>>>>> I tried USB 2.0 and the results are almost identical. >>>>>>> >>>>>>> In summary, retuning takes 450 ms in my system, every time. Michael >>>>>>> gets similar values in the first tuning, but after that there are sub ms >>>>>>> values. My app can live with a few tens of ms for retuning (100x compared >>>>>>> to Michael's results), but 450 ms is too much. >>>>>>> >>>>>>> The app performs well without retuning, reliably streaming 2x2 MIMO >>>>>>> full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>>>>> driver, or UHD version. >>>>>>> >>>>>>> At this point I'm lost. Any suggestion is appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> Are you running with external clocking? >>>>>>> >>>>>>> Is your process running with real-time scheduling, or ordinary >>>>>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>>>>> happens if >>>>>>> you use a regular kernel? >>>>>>> >>>>>>> How much memory does your system have, is it paging at all? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West < >>>>>>> michael.west@ettus.com> wrote: >>>>>>> >>>>>>>> Hi Dario, >>>>>>>> >>>>>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>>>>> will help you narrow down the issue on your system. Also, have you tried >>>>>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>>>>> are known to have issues. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Michael >>>>>>>> >>>>>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>>>>> dario.fertonani@gmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you Micheal. >>>>>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>>>>> code. Which is good news because: >>>>>>>>> >>>>>>>>> 1. It rules out the measurement error (boost vs std::chrono, >>>>>>>>> both of which I trust from past experiences). >>>>>>>>> 2. It points out that the problem is somewhere in my setup, >>>>>>>>> since I get much higher values than you do. I ran my code on two identical >>>>>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>>>>> version created problems discussed in a different thread. >>>>>>>>> >>>>>>>>> Any suggestion on what to check? Or, any chance anybody else can >>>>>>>>> run the code to see if this is really a unique problem of my setup? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West < >>>>>>>>> michael.west@ettus.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Dario, >>>>>>>>>> >>>>>>>>>> I took your code and replaced the std::chrono and std::thread >>>>>>>>>> stuff with boost equivalents and was able to achieve retuning times of >>>>>>>>>> ~150-200 microseconds after the initial tune (which took ~220 ms). No >>>>>>>>>> appreciable difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>> >>>>>>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>>>>>> in some suboptimal way? >>>>>>>>>>> I cleaned up the code so that it does nothing but retuning >>>>>>>>>>> between two frequencies. Interestingly, the retuning time doesn't vary much >>>>>>>>>>> with the frequency separation. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dario >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech < >>>>>>>>>>> mleech@ripnet.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thank you both for your answers. Anything above a few ms forces >>>>>>>>>>>> me to cross off one of the two design routes I had in mind, so " several >>>>>>>>>>>> 10s of milliseconds" leaves me with a clean path. >>>>>>>>>>>> About the frequency separation of the retuning, it could be up >>>>>>>>>>>> to one GHz. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dario >>>>>>>>>>>> >>>>>>>>>>>> I think the current code does "recal avoidance" if the re-tune >>>>>>>>>>>> is less than 100MHz. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>>>>> >>>>>>>>>>>>> Now I need to read short rx burts at frequency fC (which is >>>>>>>>>>>>> far from both fA and fB). Namely, I need to retune the rx stream to fC, >>>>>>>>>>>>> receive samples there for a little, then retune back to fB and stay there >>>>>>>>>>>>> for a long time. This goes on periodically, while the tx stream stays on fA >>>>>>>>>>>>> for the whole time. >>>>>>>>>>>>> >>>>>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>>>>> architecture. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Can I assume that the rx retuning operations do not >>>>>>>>>>>>> affect the tx stream on fA? I have a continuous stream there. >>>>>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dario >>>>>>>>>>>>> >>>>>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in >>>>>>>>>>>>> each direction are independent. Changing parameters of the RX stream will >>>>>>>>>>>>> not affect >>>>>>>>>>>>> the TX stream. >>>>>>>>>>>>> >>>>>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in >>>>>>>>>>>>> the world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> USRP-users mailing list >>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>> >>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono,
both of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup,
since I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not
affect the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Thank you Michael. I now see retuning times in line with yours. Based on this thread it would be great to have an API that allows the user to skip DC cal, for example with a flag in the tuning request class (which already has plenty of user-defined options anyway). Best, Dario On Fri, Sep 11, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > Attached is a patch (made for UHD_003.008.005-0-g7efbd15b) that reduces > the retuning time significantly. The retune time is dependent on how far > you tune. Within 100 MHz and the retune time is ~1.5 ms. Beyond 100 MHz, > it is ~170 ms due to the DC offset calibration. Some of the changes in the > patch were pulled from the UHD 3.9.1 development code base and some I > manually made. It is possible to extend the range beyond 100 MHz, but the > DC offset and IQ imbalance will get worse the larger the range is made. > > I also tested the code in the UHD 3.9.1 development code base and the > retune times were ~3.3 ms within 100 MHz and ~205 ms beyond 100 MHz, so > much of what is in the patch has already been put into UHD and will be > available in the UHD 3.9.1 release that is coming very soon. > > If the retune is within a quarter of the master clock rate from the LO > frequency, you can improve the tuning time down to a few microseconds by > tuning only the DSP frequency. I noticed you were setting the master clock > rate to 15.36e6. I would suggest setting the master clock rate to 30.72e6 > (or even 61.44e6 if running a single channel). Your sample rate can be > lower, but setting the master clock rate higher gives you more room to tune > the DSP frequency without changing the LO frequency. At a master clock > rate of 30.72, you will have a DSP tuning range of +/-7.68 MHz. If that is > sufficient range for your application, you don't need the patch at all. > > Either change to DSP tuning or give the patch a try and let me know if it > works out for you. > > Regards, > Michael > > On Fri, Sep 11, 2015 at 5:36 PM, Dario Fertonani < > dario.fertonani@gmail.com> wrote: > >> Michael, >> >> That's great news! Anything below 50 ms would work in my design. >> Also, sorry for misspelling your name earlier. >> >> Best, >> Dario >> >> >> >> On Fri, Sep 11, 2015 at 5:27 PM, Michael West <michael.west@ettus.com> >> wrote: >> >>> Hi Dario, >>> >>> I am treating it as a UHD bug for now. Tuning times should be less than >>> 400 ms. My testing so far has shown that the quadrature calibration is >>> taking most of the time. Skipping quadrature calibration reduces the >>> tuning time to only ~3.3 ms. I found another inefficiency in the tuning >>> algorithm that further reduced it down to ~1.5 ms. So there is hope. What >>> retuning range does your application require? >>> >>> Regards, >>> Michael >>> >>> On Fri, Sep 11, 2015 at 5:09 PM, Dario Fertonani < >>> dario.fertonani@gmail.com> wrote: >>> >>>> Thank you Micheal. Please keep me updated on the progress. >>>> Is it safe to assume that this is an UHD bug, or should I start >>>> thinking about a system design that doesn't rely on returning time faster >>>> than 400 ms? >>>> >>>> Thanks, >>>> Dario >>>> >>>> >>>> On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> >>>> wrote: >>>> >>>>> Hi Dario, >>>>> >>>>> It is not your set up. I have reproduced the problem. Sadly, I put >>>>> in the wrong parameters during my first tests, so it was not actually >>>>> retuning. I will dig into the issue and let you know what I find. >>>>> >>>>> Regards, >>>>> Michael >>>>> >>>>> On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < >>>>> dario.fertonani@gmail.com> wrote: >>>>> >>>>>> Michael, >>>>>> Please find attached the output file you requested. >>>>>> It is the output of the bash line >>>>>> >>>>>> ./retuneTime 739 751 &> ./retuneTime.log >>>>>> >>>>>> after I compiled your code with >>>>>> >>>>>> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >>>>>> -lboost_thread >>>>>> >>>>>> You'll notice that the retuning time is indeed above 400 ms, every >>>>>> time. >>>>>> About your profiling suggestion... I'm profiling the time taken to >>>>>> execute >>>>>> >>>>>> set_rx_freq >>>>>> >>>>>> and nothing more. Are you suggesting I profile what UHD actually does >>>>>> within that call? If so, could you please send me a command line with perf >>>>>> usage? >>>>>> >>>>>> Marcus, >>>>>> I'm running internal clock and real-time scheduling. I installed the >>>>>> regular kernel (as opposed to the low-latency kernel that is my default) >>>>>> and the results are identical. System memory/cache isn't a problem. The >>>>>> code just loops over retuning calls, without streaming anything, so really >>>>>> the system horsepower isn't a problem here. >>>>>> >>>>>> In general, I was hoping there was an API usage problem on my side, >>>>>> which doesn't seem to be the case. This system is good enough to stream and >>>>>> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >>>>>> hard to believe that the same system needs 400 ms just to retune. I tried >>>>>> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >>>>>> all give the same result. I tried different UHD versions and different CPUs >>>>>> (all Haswell 3.6 GHz or better). >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Sep 11, 2015 at 12:58 PM, Michael West < >>>>>> michael.west@ettus.com> wrote: >>>>>> >>>>>>> Hi Dario, >>>>>>> >>>>>>> Try to run perf to profile the system while running the >>>>>>> application. It should give you an indication on where the CPU time is >>>>>>> being spent. >>>>>>> >>>>>>> Also, just to clarify, I changed the units from milliseconds to >>>>>>> microseconds in the code I modified and I want to make sure you were not >>>>>>> misinterpreting the results. Can you send me the actual output from >>>>>>> running that code for my own sanity? >>>>>>> >>>>>>> Thanks, >>>>>>> Michael >>>>>>> >>>>>>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech <mleech@ripnet.com >>>>>>> > wrote: >>>>>>> >>>>>>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>>>>>> >>>>>>>> I tried USB 2.0 and the results are almost identical. >>>>>>>> >>>>>>>> In summary, retuning takes 450 ms in my system, every time. Michael >>>>>>>> gets similar values in the first tuning, but after that there are sub ms >>>>>>>> values. My app can live with a few tens of ms for retuning (100x compared >>>>>>>> to Michael's results), but 450 ms is too much. >>>>>>>> >>>>>>>> The app performs well without retuning, reliably streaming 2x2 MIMO >>>>>>>> full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>>>>>> driver, or UHD version. >>>>>>>> >>>>>>>> At this point I'm lost. Any suggestion is appreciated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dario >>>>>>>> >>>>>>>> Are you running with external clocking? >>>>>>>> >>>>>>>> Is your process running with real-time scheduling, or ordinary >>>>>>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>>>>>> happens if >>>>>>>> you use a regular kernel? >>>>>>>> >>>>>>>> How much memory does your system have, is it paging at all? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West < >>>>>>>> michael.west@ettus.com> wrote: >>>>>>>> >>>>>>>>> Hi Dario, >>>>>>>>> >>>>>>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>>>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>>>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>>>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>>>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>>>>>> will help you narrow down the issue on your system. Also, have you tried >>>>>>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>>>>>> are known to have issues. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>>>>>> dario.fertonani@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Thank you Micheal. >>>>>>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>>>>>> code. Which is good news because: >>>>>>>>>> >>>>>>>>>> 1. It rules out the measurement error (boost vs std::chrono, >>>>>>>>>> both of which I trust from past experiences). >>>>>>>>>> 2. It points out that the problem is somewhere in my setup, >>>>>>>>>> since I get much higher values than you do. I ran my code on two identical >>>>>>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>>>>>> version created problems discussed in a different thread. >>>>>>>>>> >>>>>>>>>> Any suggestion on what to check? Or, any chance anybody else can >>>>>>>>>> run the code to see if this is really a unique problem of my setup? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dario >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West < >>>>>>>>>> michael.west@ettus.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dario, >>>>>>>>>>> >>>>>>>>>>> I took your code and replaced the std::chrono and std::thread >>>>>>>>>>> stuff with boost equivalents and was able to achieve retuning times of >>>>>>>>>>> ~150-200 microseconds after the initial tune (which took ~220 ms). No >>>>>>>>>>> appreciable difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Michael >>>>>>>>>>> >>>>>>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users >>>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> The attached example gives me retuning times of 400 ms or more, >>>>>>>>>>>> which is order of magnitudes beyond what is expected. Am I calling the API >>>>>>>>>>>> in some suboptimal way? >>>>>>>>>>>> I cleaned up the code so that it does nothing but retuning >>>>>>>>>>>> between two frequencies. Interestingly, the retuning time doesn't vary much >>>>>>>>>>>> with the frequency separation. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dario >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech < >>>>>>>>>>>> mleech@ripnet.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you both for your answers. Anything above a few ms >>>>>>>>>>>>> forces me to cross off one of the two design routes I had in mind, so " >>>>>>>>>>>>> several 10s of milliseconds" leaves me with a clean path. >>>>>>>>>>>>> About the frequency separation of the retuning, it could be up >>>>>>>>>>>>> to one GHz. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dario >>>>>>>>>>>>> >>>>>>>>>>>>> I think the current code does "recal avoidance" if the re-tune >>>>>>>>>>>>> is less than 100MHz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now I need to read short rx burts at frequency fC (which is >>>>>>>>>>>>>> far from both fA and fB). Namely, I need to retune the rx stream to fC, >>>>>>>>>>>>>> receive samples there for a little, then retune back to fB and stay there >>>>>>>>>>>>>> for a long time. This goes on periodically, while the tx stream stays on fA >>>>>>>>>>>>>> for the whole time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>>>>>> architecture. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Can I assume that the rx retuning operations do not >>>>>>>>>>>>>> affect the tx stream on fA? I have a continuous stream there. >>>>>>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dario >>>>>>>>>>>>>> >>>>>>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains >>>>>>>>>>>>>> in each direction are independent. Changing parameters of the RX stream >>>>>>>>>>>>>> will not affect >>>>>>>>>>>>>> the TX stream. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in >>>>>>>>>>>>>> the world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just to add a little more to Marcus's reply. The distance you >>>>>>>>>>>>>> retune (in Hertz) affects the settling time. Certain re-calibrations are >>>>>>>>>>>>>> triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono,
both of which I trust from past experiences).
2. It points out that the problem is somewhere in my setup,
since I get much higher values than you do. I ran my code on two identical
setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4
GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest
version created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not
affect the tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm
looking for the time after which retuning is done AND everything is
settled, so that the samples streamed from the new frequency are clean.

Hi Dario, Excellent. I'm glad it worked. Thanks for the feedback. We have already been discussing how to improve it and will certainly take your suggestion under consideration. Regards, Michael On Fri, Sep 11, 2015 at 8:56 PM, Dario Fertonani <dario.fertonani@gmail.com> wrote: > Thank you Michael. I now see retuning times in line with yours. > Based on this thread it would be great to have an API that allows the user > to skip DC cal, for example with a flag in the tuning request class (which > already has plenty of user-defined options anyway). > > Best, > Dario > > > > > > On Fri, Sep 11, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> Attached is a patch (made for UHD_003.008.005-0-g7efbd15b) that reduces >> the retuning time significantly. The retune time is dependent on how far >> you tune. Within 100 MHz and the retune time is ~1.5 ms. Beyond 100 MHz, >> it is ~170 ms due to the DC offset calibration. Some of the changes in the >> patch were pulled from the UHD 3.9.1 development code base and some I >> manually made. It is possible to extend the range beyond 100 MHz, but the >> DC offset and IQ imbalance will get worse the larger the range is made. >> >> I also tested the code in the UHD 3.9.1 development code base and the >> retune times were ~3.3 ms within 100 MHz and ~205 ms beyond 100 MHz, so >> much of what is in the patch has already been put into UHD and will be >> available in the UHD 3.9.1 release that is coming very soon. >> >> If the retune is within a quarter of the master clock rate from the LO >> frequency, you can improve the tuning time down to a few microseconds by >> tuning only the DSP frequency. I noticed you were setting the master clock >> rate to 15.36e6. I would suggest setting the master clock rate to 30.72e6 >> (or even 61.44e6 if running a single channel). Your sample rate can be >> lower, but setting the master clock rate higher gives you more room to tune >> the DSP frequency without changing the LO frequency. At a master clock >> rate of 30.72, you will have a DSP tuning range of +/-7.68 MHz. If that is >> sufficient range for your application, you don't need the patch at all. >> >> Either change to DSP tuning or give the patch a try and let me know if it >> works out for you. >> >> Regards, >> Michael >> >> On Fri, Sep 11, 2015 at 5:36 PM, Dario Fertonani < >> dario.fertonani@gmail.com> wrote: >> >>> Michael, >>> >>> That's great news! Anything below 50 ms would work in my design. >>> Also, sorry for misspelling your name earlier. >>> >>> Best, >>> Dario >>> >>> >>> >>> On Fri, Sep 11, 2015 at 5:27 PM, Michael West <michael.west@ettus.com> >>> wrote: >>> >>>> Hi Dario, >>>> >>>> I am treating it as a UHD bug for now. Tuning times should be less >>>> than 400 ms. My testing so far has shown that the quadrature calibration >>>> is taking most of the time. Skipping quadrature calibration reduces the >>>> tuning time to only ~3.3 ms. I found another inefficiency in the tuning >>>> algorithm that further reduced it down to ~1.5 ms. So there is hope. What >>>> retuning range does your application require? >>>> >>>> Regards, >>>> Michael >>>> >>>> On Fri, Sep 11, 2015 at 5:09 PM, Dario Fertonani < >>>> dario.fertonani@gmail.com> wrote: >>>> >>>>> Thank you Micheal. Please keep me updated on the progress. >>>>> Is it safe to assume that this is an UHD bug, or should I start >>>>> thinking about a system design that doesn't rely on returning time faster >>>>> than 400 ms? >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> >>>>> On Fri, Sep 11, 2015 at 4:22 PM, Michael West <michael.west@ettus.com> >>>>> wrote: >>>>> >>>>>> Hi Dario, >>>>>> >>>>>> It is not your set up. I have reproduced the problem. Sadly, I put >>>>>> in the wrong parameters during my first tests, so it was not actually >>>>>> retuning. I will dig into the issue and let you know what I find. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> On Fri, Sep 11, 2015 at 3:56 PM, Dario Fertonani < >>>>>> dario.fertonani@gmail.com> wrote: >>>>>> >>>>>>> Michael, >>>>>>> Please find attached the output file you requested. >>>>>>> It is the output of the bash line >>>>>>> >>>>>>> ./retuneTime 739 751 &> ./retuneTime.log >>>>>>> >>>>>>> after I compiled your code with >>>>>>> >>>>>>> g++ retuneTime.cpp -o retuneTime -std=c++11 -O3 -luhd -lboost_system >>>>>>> -lboost_thread >>>>>>> >>>>>>> You'll notice that the retuning time is indeed above 400 ms, every >>>>>>> time. >>>>>>> About your profiling suggestion... I'm profiling the time taken to >>>>>>> execute >>>>>>> >>>>>>> set_rx_freq >>>>>>> >>>>>>> and nothing more. Are you suggesting I profile what UHD actually >>>>>>> does within that call? If so, could you please send me a command line with >>>>>>> perf usage? >>>>>>> >>>>>>> Marcus, >>>>>>> I'm running internal clock and real-time scheduling. I installed the >>>>>>> regular kernel (as opposed to the low-latency kernel that is my default) >>>>>>> and the results are identical. System memory/cache isn't a problem. The >>>>>>> code just loops over retuning calls, without streaming anything, so really >>>>>>> the system horsepower isn't a problem here. >>>>>>> >>>>>>> In general, I was hoping there was an API usage problem on my side, >>>>>>> which doesn't seem to be the case. This system is good enough to stream and >>>>>>> process continuously 2x2 MIMO full-duplex signals at 7.68 MHz, so I find it >>>>>>> hard to believe that the same system needs 400 ms just to retune. I tried >>>>>>> USB power, dedicated power, one antenna, two antennas, rx only, rx+tx, and >>>>>>> all give the same result. I tried different UHD versions and different CPUs >>>>>>> (all Haswell 3.6 GHz or better). >>>>>>> >>>>>>> Thanks, >>>>>>> Dario >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 11, 2015 at 12:58 PM, Michael West < >>>>>>> michael.west@ettus.com> wrote: >>>>>>> >>>>>>>> Hi Dario, >>>>>>>> >>>>>>>> Try to run perf to profile the system while running the >>>>>>>> application. It should give you an indication on where the CPU time is >>>>>>>> being spent. >>>>>>>> >>>>>>>> Also, just to clarify, I changed the units from milliseconds to >>>>>>>> microseconds in the code I modified and I want to make sure you were not >>>>>>>> misinterpreting the results. Can you send me the actual output from >>>>>>>> running that code for my own sanity? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michael >>>>>>>> >>>>>>>> On Fri, Sep 11, 2015 at 11:42 AM, Marcus D. Leech < >>>>>>>> mleech@ripnet.com> wrote: >>>>>>>> >>>>>>>>> On 09/11/2015 02:37 PM, Dario Fertonani wrote: >>>>>>>>> >>>>>>>>> I tried USB 2.0 and the results are almost identical. >>>>>>>>> >>>>>>>>> In summary, retuning takes 450 ms in my system, every time. >>>>>>>>> Michael gets similar values in the first tuning, but after that there are >>>>>>>>> sub ms values. My app can live with a few tens of ms for retuning (100x >>>>>>>>> compared to Michael's results), but 450 ms is too much. >>>>>>>>> >>>>>>>>> The app performs well without retuning, reliably streaming 2x2 >>>>>>>>> MIMO full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB >>>>>>>>> driver, or UHD version. >>>>>>>>> >>>>>>>>> At this point I'm lost. Any suggestion is appreciated. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dario >>>>>>>>> >>>>>>>>> Are you running with external clocking? >>>>>>>>> >>>>>>>>> Is your process running with real-time scheduling, or ordinary >>>>>>>>> scheduling? You mentioned you're using the "low-latency" kernel, what >>>>>>>>> happens if >>>>>>>>> you use a regular kernel? >>>>>>>>> >>>>>>>>> How much memory does your system have, is it paging at all? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Sep 11, 2015 at 10:32 AM, Michael West < >>>>>>>>> michael.west@ettus.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Dario, >>>>>>>>>> >>>>>>>>>> My original run was based on our UHD 3.9.1 development branch. I >>>>>>>>>> re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and >>>>>>>>>> observed that the initial tuning took 477 milliseconds and retuning took >>>>>>>>>> ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu >>>>>>>>>> 14.04. Perhaps running perf to profile the system while running the code >>>>>>>>>> will help you narrow down the issue on your system. Also, have you tried >>>>>>>>>> using USB 2.0 to see if there is a difference? Some USB 3.0 controllers >>>>>>>>>> are known to have issues. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Michael >>>>>>>>>> >>>>>>>>>> On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < >>>>>>>>>> dario.fertonani@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you Micheal. >>>>>>>>>>> I ran your code and found the same values (400 ms or more) as my >>>>>>>>>>> code. Which is good news because: >>>>>>>>>>> >>>>>>>>>>> 1. It rules out the measurement error (boost vs std::chrono, >>>>>>>>>>> both of which I trust from past experiences). >>>>>>>>>>> 2. It points out that the problem is somewhere in my setup, >>>>>>>>>>> since I get much higher values than you do. I ran my code on two identical >>>>>>>>>>> setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 >>>>>>>>>>> GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest >>>>>>>>>>> version created problems discussed in a different thread. >>>>>>>>>>> >>>>>>>>>>> Any suggestion on what to check? Or, any chance anybody else can >>>>>>>>>>> run the code to see if this is really a unique problem of my setup? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dario >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Sep 10, 2015 at 7:30 PM, Michael West < >>>>>>>>>>> michael.west@ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Dario, >>>>>>>>>>>> >>>>>>>>>>>> I took your code and replaced the std::chrono and std::thread >>>>>>>>>>>> stuff with boost equivalents and was able to achieve retuning times of >>>>>>>>>>>> ~150-200 microseconds after the initial tune (which took ~220 ms). No >>>>>>>>>>>> appreciable difference over USB 2.0 or 3.0. The modified code is attached. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Michael >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users >>>>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The attached example gives me retuning times of 400 ms or >>>>>>>>>>>>> more, which is order of magnitudes beyond what is expected. Am I calling >>>>>>>>>>>>> the API in some suboptimal way? >>>>>>>>>>>>> I cleaned up the code so that it does nothing but retuning >>>>>>>>>>>>> between two frequencies. Interestingly, the retuning time doesn't vary much >>>>>>>>>>>>> with the frequency separation. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dario >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech < >>>>>>>>>>>>> mleech@ripnet.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you both for your answers. Anything above a few ms >>>>>>>>>>>>>> forces me to cross off one of the two design routes I had in mind, so " >>>>>>>>>>>>>> several 10s of milliseconds" leaves me with a clean path. >>>>>>>>>>>>>> About the frequency separation of the retuning, it could be >>>>>>>>>>>>>> up to one GHz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dario >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the current code does "recal avoidance" if the >>>>>>>>>>>>>> re-tune is less than 100MHz. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>>>>>>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Currently my application runs continuous tx and rx on two >>>>>>>>>>>>>>> different frequencies, with B210 in full-duplex MIMO configuration. Let's >>>>>>>>>>>>>>> call fA the tx freq and fB the rx freq. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now I need to read short rx burts at frequency fC (which is >>>>>>>>>>>>>>> far from both fA and fB). Namely, I need to retune the rx stream to fC, >>>>>>>>>>>>>>> receive samples there for a little, then retune back to fB and stay there >>>>>>>>>>>>>>> for a long time. This goes on periodically, while the tx stream stays on fA >>>>>>>>>>>>>>> for the whole time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The following questions are critical for the design of the >>>>>>>>>>>>>>> architecture. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Can I assume that the rx retuning operations do not >>>>>>>>>>>>>>> affect the tx stream on fA? I have a continuous stream there. >>>>>>>>>>>>>>> 2. What is a ballpark value for the retuning time? I'm >>>>>>>>>>>>>>> looking for the time after which retuning is done AND everything is >>>>>>>>>>>>>>> settled, so that the samples streamed from the new frequency are clean. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Dario >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains >>>>>>>>>>>>>>> in each direction are independent. Changing parameters of the RX stream >>>>>>>>>>>>>>> will not affect >>>>>>>>>>>>>>> the TX stream. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For (2), the AD9361 is not the fastest-locking synthesizer >>>>>>>>>>>>>>> in the world. There's not only the lock-time, but also a *lot* of internal >>>>>>>>>>>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>>>>>>>>>>> Ballpark would be several 10s of milliseconds. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just to add a little more to Marcus's reply. The distance >>>>>>>>>>>>>>> you retune (in Hertz) affects the settling time. Certain re-calibrations >>>>>>>>>>>>>>> are triggered when this exceeds a threshold. How far is "far"? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >