On Tue, Aug 19, 2025 at 11:23 AM niels.steffen.garibaldi--- via USRP-users <
usrp-users@lists.ettus.com> wrote:

> 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
>
Niels makes excellent points. You should listen to him!

Brian
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to