I suspect that a more dynamic analysis would be required. Further, allowing only 2ms for the PLL to lock is cutting it way close—depending on the particular daughter card.
Sent from my iPhone > On Jun 11, 2020, at 4:47 PM, Lukas Haase <[email protected]> wrote: > > 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" <[email protected]> >> An: "Lukas Haase" <[email protected]> >> Cc: "USRP-userslists.ettus.com" <[email protected]> >> 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 <[email protected]> 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 [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
