On 06/12/2020 11:44 AM, Lukas Haase via USRP-users wrote:
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
The data stream is buffered, but commands are executed directly without
Gnu Radio, per se, "getting in the way". Now, if those commands
originate in *messages*, then things are a bit different, and I'm not
sure of how messages are buffered and managed, although certainly
there'll be some amount of latency inherent in using the message
system to produce commands.
There'll be latency differences between commands that originate purely
in Python land, and those that originate in C++ code--since you
necessarily have to deal with Python interpreter latency. In either
case, if you're doing "very tight" scheduling, on a general-purpose OS
like Linux, you cannot have any guarantees about latency
predictability. The "safe" thing to do would be to schedule things
probably at
least 10s of milliseconds in advance to make certain that your
commands make it out of the host in time.
Gesendet: Freitag, 12. Juni 2020 um 07:04 Uhr
Von: "Chintan Patel" <[email protected]>
An: "Lukas Haase" <[email protected]>
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
<[email protected][mailto:[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[https://files.ettus.com/manual/page_transport.html]
Gesendet: Donnerstag, 11. Juni 2020 um 16:32 Uhr
Von: "Marcus D Leech" <[email protected][mailto:[email protected]]>
An: "Lukas Haase" <[email protected][mailto:[email protected]]>
Cc: "USRP-userslists.ettus.com[http://USRP-userslists.ettus.com]";
<[email protected][mailto:[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][mailto:[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][mailto:[email protected]]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
