You want the “dboard” files in the UHD source. They subscribe to internal tuning events. Use whichever dboard files correspond to your hardware.
Sent from my iPhone > On Jun 11, 2020, at 4:32 PM, Marcus D Leech <patchvonbr...@gmail.com> wrote: > > So one of the things That can happen is that your command packets will have > to wait For a much-larger data packet. The link is shared. > > I’d timed commands are scheduled “tight” this can happen. > > Sent from my iPhone > >> On Jun 11, 2020, at 3:34 PM, Lukas Haase <lukasha...@gmx.at> wrote: >> >> Hi Marcus, >> >>>>> On 06/10/2020 09:00 PM, Lukas Haase via USRP-users wrote: >>>>> [...] >>>>> For example, what is the fastest rate I can issue timed commands >>>>> (ignoring settling times etc) on a X310 over 10Gbe? >>> This is actually an ambiguous question. Do you mean "what is the >>> smallest scheduling interval for the commands that will be executed >>> in the future?" or "how fast can I issue commands that will >>> ultimately be scheduled at a later time?" In the former, that >>> depends on the exact nature of the commands, since they end up >>> actually being executed by, for example, an SPI or I2C endpoint, >>> which operates very very much slower than a 10GiGe interface. In the >>> latter, my guess is that the FPGA can swallow commands and place them >>> on the queue pretty-much as fast as you can issue them over 10GiG. >>> How fast you can do that depends very much on your host-side >>> environment, network stack, kernel network drivers, kernel latencies, >>> etc. >> >> My questions concerns the latter (for now). >> Since the FPGA has a (small) finite FIFO for these timed commands I >> assume*d* there would be a limit on how fast I can send these commands. >> >> Based on Jonathon's answer however, it seems that UHD on the host ensures >> that it only sends a maximum number of timed commands such that the command >> queues do not overflow. >> >> But it seems to bring another issue: If UHD holds back these messages too >> long they will eventually arrive late and (silently) execute non-timed >> (thereby destroying any coherence the application might require). >> >> I am trying to debug WHY this can happen, why it does NOT happen to the data >> stream (all data arrives on time!) and what I can do that I ensure my timed >> commands will execute *on time*. >> >> Thanks, >> Lukas >> >> >> >> >> >> _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
