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
