Hi Arthur,\
\
Have you tried using tcpdump/wireshark on your machine to check the
communication/timing of the control transmissions going over the ethernet
connection?\
As far as I am aware all UHD (Control) messages are using UDP, so your
suspicion regarding TCP algorithm slowdown should not hold as there is no TCP
used.\
\
Depending on your network topology, it might be the case that the slow down you
are seeing is due to your application constantly checking for fullness.\
I recently looked into an issue where I took some wireshark logs and saw that
even if i just did a register read operation the time it took between when the
read request was sent out and when the read response with the ACKnowledgement
took a little bit of time, if both host and SDR were even connected to a single
switch. \
\
Here is a snippet of one of my logs showing two register reads(what your
fullness function using peek32 almost definitely uses.), that both took \~275us
between request and response.
Even with a direct connection, it might take a little bit of time to query the
block command queue fullness.
What I suspect is happening is that the fullness query you are doing every
cycle of your inner loop is at least in some cases blocking for longer than
your interpulse duration.\
\
You could try the follwoing:\
- Send a single timed command and see how many spots in the queue it takes
up(depending on the command it could be more than one.)\
- Then when you are querying, instead of checking if ther is at least one
space, check if there is X spaces and then send out the next X timed commands
out one after the other.
That way you probably only need to query the queue fill state once every couple
of milliseconds which should be doable.\
\
Otherwise, if you are experienced with making HDL changes, you could also
replace the [fixed 32 space axi_fifo_short command FIFO
module](https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_replay/axis_replay.v#L529)
with a size configurable axi_fifo with increased width, to see if that
circumvents your issues.\
\
Disclaimer: I am more of an FPGA developer so take any SW advice I might give
with a grain of salt.\
\
Regards,\
\
Niels
P.S.: Seems like Brian was a little bit faster, but he does mention some
similar points
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
