Hi Chintan, That's a good thought.
What concerns me is that whether timed commands are executed properly seems to depend on second and third level parameters such as the way in which I connect blocks in gnuradio. This is problematic because even if I figure out the max. rate with the scope, once I add another block, things may behave differently. I think the reason that this depends on how blocks are connected in gnuradio are buffers. In other words, how fast and how much data UHD receives at once. All my data arrives on time, just timed commands are sometimes late (the cause and conditions are unclear). There must be a way to control this properly in UHD. The link speed is way fast enough (10Gbe and I use 20Msps). Thanks, Lukas Gesendet: Freitag, 12. Juni 2020 um 07:04 Uhr Von: "Chintan Patel" <cpa...@vt.edu> An: "Lukas Haase" <lukasha...@gmx.at> Betreff: Re: [USRP-users] How to debug timed commands on FPGA side? Lukas, I may have missed some salient points of this thread, but here's a thought. Could you just alternate between sending two timed commands - transmit freq A and transmit freq B. Hook up the output to a scope (spec an may not react fast enough). Once you have the setup that you can "see" whether a command has been processed or not by looking at the scope, you can characterize the reliable ingest rate of the timed command, empirically? If using a scope is not feasible, if you have another SDR, you can use the SDR to capture data (instead of scope) to see whether all TX tune commands were processed correctly. A thought. Chintan On Thu, Jun 11, 2020 at 4:47 PM Lukas Haase via USRP-users <usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> 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[https://files.ettus.com/manual/page_transport.html] > Gesendet: Donnerstag, 11. Juni 2020 um 16:32 Uhr > Von: "Marcus D Leech" > <patchvonbr...@gmail.com[mailto:patchvonbr...@gmail.com]> > An: "Lukas Haase" <lukasha...@gmx.at[mailto:lukasha...@gmx.at]> > Cc: "USRP-userslists.ettus.com[http://USRP-userslists.ettus.com]"; > <usrp-users@lists.ettus.com[mailto: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[mailto: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[mailto: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
