Re: [USRP-users] get_time_now() blocking?

Wed, 24 Apr 2019 18:17:04 -0700 

On 04/24/2019 04:16 AM, Fabian Schwartau via USRP-users wrote:

To answer my own question: Yes, it does.
Even when calling clear_command_time(), the get_time_now() will be executed (and thus return) after the last commited command was executed, no matter what command it was. Additionally if the last command is too far in the future, get_time_now() will fail and throw an exception, saying that the USRP did not respond.
The "waits until the queue has execute" behavior is expected and design-intent. 


The timeout is probably also, in a sense, design-intent, but fails the 
"least astonishment test".  In the normal case, the command is sent to the
  device, and it is expected that a response packet will come back "in 
a reasonable time".  But in this particular case, the response won't arrive
  until all the commands have executed, and that can exceed the 
protocol-timeout window.



This is, I admit,  "a bit rough", and I suspect that there are other 
cases in timed-commands where this sort of thing happens as well.





Am 23.04.2019 um 22:54 schrieb Fabian Schwartau via USRP-users:

Hmm does this also mean that get_time_now will block if there are 
other commands issued before that with a later execution? That might 
explain my issues.



Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via 
USRP-users" <usrp-users@lists.ettus.com>:


    On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:

        Hi,

        well, ...

        I am recording small slots (up to 2 seconds) of data at 
different

        frequencies, gain, sample rates, etc. I have written a manager
        for the
        USRP where other classes can ask for a certain slot (frequency,
        sample
        count, sample rate, ...). The manager does not know when someone
        will
        ask for data. So it happens that there is nothing to do. In that
        case
        the manager looses track of the current time and does not know
        when to
        start the next command once someone asks for a new slot. In this
        case
        he gets the current time, adds a few hundred ms to be on the
        safe side
        and continues. Even if I would be able to plan that far ahead, I
        found
        out that the USRP is not able to plan commands that are quite
        far in
        the future (it was like 10 seconds or so). Starnge things happen
        and I
        also loose track of the time.
        One more reason is that the USRP is not capable of timed sample
        rate

        switches (was discusses here a few month back) which means 
that the

        manager has to wait until all pending commands are done and the
        data
        is received, then switch the sample rate, get the current time
        (as the

        processing/download of the data in the other thread may take 
some

        time), again add a few hundred ms and continue.
        Actually I am currently quite pissed as I run into one bug after
        another and cannot continue my actual work. I found like another
        three
        critical bugs, but I cannot reporoduce them in smaller programs
        and I

        do not have the time to debug the full UHD library. So I 
write one

        workaround after another.

        Best regards,
        Fabian

    Also, get_time_now() is controlled by set_command_time(). So, for

    example, if you have two threads issuing control commands, and 
one thread

        issues a set_command_time(), and then another thread issues a

    get_time_now() while there's a set_command_time() window pending, 
it will
        be controlled by the set_command_time().   The USRP device 
has zero
    concept of threading, per se, so it's up to the application to 
keep track

        of stuff like this.
------------------------------------------------------------------------
    USRP-users mailing list
    USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

_______________________________________________
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



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






















					Reply via email to