Hi Marcus, Can we quantify this in the following way?
If I send timed commands every 2ms and sampling rate is 5MS/s, that's 10000 samples per command or 50000 for the command queue (assuming a depth of 5). Can we say the timed commands will guaranteed to be executed on time if we never buffer more than 50000 samples (=200000 bytes) on the host? Can this be tuned somehow? I tried setting send_buff_size [1] to a small value (send_buff_size=10000 etc.) but that didn't seem to make any difference. Thanks, Lukas [1] https://files.ettus.com/manual/page_transport.html > Gesendet: Donnerstag, 11. Juni 2020 um 16:32 Uhr > Von: "Marcus D Leech" <patchvonbr...@gmail.com> > An: "Lukas Haase" <lukasha...@gmx.at> > Cc: "USRP-userslists.ettus.com" <usrp-users@lists.ettus.com> > Betreff: Re: [USRP-users] How to debug timed commands on FPGA side? > > 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
