Fabian, It probably helps to try to understand the hardware a little, and then the way that timed commands operate will be a little bit more intuitive.
Only certain parts of the actual USRP have access to accurate time (Those parts running on the so called “Radio clock” which is an integer multiple of the sample rate). Some portions run on asynchronous (to the radio) clocks or interact with 3rd party H/W that has non deterministic execution or access timing. Commands in the UHD API that control or access the H/W decompose into one or more memory mapped register reads and writes inside the USRP, and it is these reads and writes that are optionally tagged with time metadata derived from the set_command_time() API call. These reads and writes are placed into multiple strictly ordered queues (Where the queue itself bridges the S/W and H/W domains and the intervening network interface) and only the execution of the command at the head of the queue can cause the queue to advance. The order of execution is determined solely by the order that transactions were added to the queue. If it is a queue that supports time, then the command at the head of the queue will block until it’s execution time is reached. Other commands behind it in the queue, regardless of whether they have an explicit execution time will not be considered for execution until they are the transaction at the head. If it is a queue that has no knowledge of time, then commands will have no time metadata and all commands will execute asynchronously, in strict order, as fast as possible. Different queues operate completely independently, for example a timed command to a particular Radio would block all subsequent commands to that Radio, but a different Radio with a separate queue would not be blocked. Each different model of USRP has different queues, and occasionally queues for a given USRP model may change across a major UHD revision, and the typical USRP user would be a little overwhelmed by this level of detail. UHD does it’s best to make all USRP’s appear to operate consistently but it’s not perfect at hiding the subtle differences in H/W impementation that span nearly 15 years of H/W designs. -Ian > On Apr 24, 2019, at 11:33 PM, Fabian Schwartau via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hi, > > thanks for clarification. > It would be great if there would be a more detailed description of the timed > command behaviour on the wiki. For example a list clarifying which commands > are affected by set_command_time and which are not. The fact that switching > sample rates using timed commands should jump right in your face at multiple > points of the documentation in big red letters - you know what I mean ;) > > Best regards, > Fabian > > Am 25.04.2019 um 03:15 schrieb Marcus D. Leech via USRP-users: >> 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 > > _______________________________________________ > 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
