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