I'm receiving the correct signal and number of items received. But the buffer is not freed. After ~25 MBs I start getting OOs, until it stalls. GDB shows that it skips uhd code updating the pointer in the source buffer. That's bad:(
Nikos On Fri, Aug 1, 2025 at 3:32 PM Martin Braun <martin.br...@ettus.com> wrote: > The return value of recv() is the number of items that are pulled from the > receive buffer, and are copied to your OpenCL buffer. When it returns, > that's the amount of space freed in the receive buffer. > > --M > > On Fri, Aug 1, 2025 at 7:47 AM Nikos Balkanas <nbalka...@gmail.com> wrote: > >> Seems it runs through >> host/lib/include/uhdlib/transport/rx_streamer_impl.hpp: 137 >> -> _recv_one_packet() : 276 >> -> _convert_to_out_buff() >> -> _converters[chan]->conv(buffer_ptr, out_buffs, num_samps); 362 >> -> host/include/uhd/convert.hpp:35 >> -> host/lib/convert/sse2_sc16_to_fc32.cpp: 124 >> -> chdr_sc16_to_xx : 173 >> -> host/lib/convert/convert_common.hpp: 198 >> Where it does the generic (non-sse2) conversion. >> When it returns it goes back >> to host/lib/include/uhdlib/transport/rx_streamer_impl.hpp: 137 and returns. >> It should have gone instead >> to host/lib/include/uhdlib/transport/rx_streamer_impl.hpp: 362 to continue. >> Next line would be: // Advance the pointer for the source buffer >> which is never executed:( >> >> I cannot test if this is the OO problem, since gdb has a bug with >> breakpoint locations. >> The code in converters seems to mess up the memory for the IR register >> (AMD CPU - next instruction) >> >> BR >> Nikos >> >> On Fri, Aug 1, 2025 at 12:55 AM Nikos Balkanas <nbalka...@gmail.com> >> wrote: >> >>> I always read my buffers. That's the whole point. Not using my X310 for >>> anything else. >>> Not transmitting anything. >>> Besides, between your X310 estimations and my calculations, it turns >>> out, that *no buffer* is ever cleared. >>> I could understand missing a couple of reads, which I don't, but all of >>> them? >>> The buffer current pointer is advanced fine. I always read in the new >>> data, never the same. >>> But it doesn't delete the old reads below the current pointer:( >>> Maybe it has to do with the "strange memory" I use. >>> UHD uses a lot of "weird" code that is not very portable. >>> What UHD file is it? I need to check it, and run it through gdb... >>> >>> TIA >>> Nikos >>> >>> On Thu, Jul 31, 2025 at 11:25 PM Martin Braun <martin.br...@ettus.com> >>> wrote: >>> >>>> It sounds like you are not permanently reading samples. Everytime >>>> rx_streamer::recv() returns, the samples are "removed" from the buffers. >>>> >>>> --M >>>> >>>> On Thu, Jul 31, 2025 at 8:04 PM Nikos Balkanas <nbalka...@gmail.com> >>>> wrote: >>>> >>>>> Thanks Martin, >>>>> >>>>> for your fast response. >>>>> My bad not mentioning my setup. But you got them right:) >>>>> Ubuntu 24.04, UHD 4.6, X310, 10 Gbe line. >>>>> >>>>> 1) Yup. I start the recv() right after I start the streamer. >>>>> 2) Can't change that. Buffers are created in OpenCL and am mapping >>>>> them to the host side to write them. They are limited to the FFT size, >>>>> 1024 >>>>> samples. >>>>> >>>>> The interesting thing is that at first I am using an FFT batch size of >>>>> 16x, that is 16384 samples. >>>>> That means that I have to back and get more samples 16x! >>>>> However, i am not getting the OOs then. >>>>> Later on, I only do a single pass, .num_samples = 1024, just enough >>>>> for 1 FFT, for now. This might change in the future. >>>>> But this is where I'm getting the OO's. >>>>> My test results, couldn't get OO's with 3e5 samples ~ 5 MB in 11 hrs. >>>>> That shows that rx_streamer buffers are larger than 5 MB, in line with >>>>> your >>>>> estimation of 25 MBs:) >>>>> These are big buffers:) >>>>> Doing a few calculations, I read 1133 samples in 16x mode ~18.5 MB + >>>>> 6.054 MB in 1x single FFT mode ~24.6 MBs before OOs appear. >>>>> Seems that I don't read anything! But I read every single sample:( >>>>> Must be that rx_streamer delivers the samples but doesn't reduce its >>>>> buffers... >>>>> >>>>> This shouldn't be happening. Where in UHD sources is this controlled? >>>>> >>>>> TIA >>>>> Nikos >>>>> >>>>> On Thu, Jul 31, 2025 at 12:00 PM Martin Braun <martin.br...@ettus.com> >>>>> wrote: >>>>> >>>>>> The size of the recv buffer depends on a bunch of things. On X310, >>>>>> when using 10 GbE, UHD will try and make the socket buffer 25MB in size. >>>>>> Until the socket buffer is full, there will be no overrun. >>>>>> >>>>>> BTW if you want to find O in UHD, grep for "\<O\>" (or ag "\bO\b"). >>>>>> But you don't have to, I can tell you that you will end up in >>>>>> radio_control_impl.cpp. >>>>>> >>>>>> There are several knobs for you to tune: >>>>>> >>>>>> - Are you starting your recv() call soon enough, or is the radio >>>>>> streaming before you recv? >>>>>> - Can you increase the buffer size that you pass into recv? In an >>>>>> extreme case, you would pass a buffer that is big enough for all >>>>>> num_samps, >>>>>> and let UHD handle it. >>>>>> >>>>>> Also, what's your rate, your device, your transport... >>>>>> >>>>>> --M >>>>>> >>>>>> On Thu, Jul 31, 2025 at 10:17 AM Nikos Balkanas <nbalka...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Did some more testing. Tried to fill rx_streamer's buffers in >>>>>>> purpose. >>>>>>> .stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE >>>>>>> streamer timeout set to 3". >>>>>>> >>>>>>> 1) .num_samples = 16384. Read 1024 each time in a loop sleeping 1" >>>>>>> each turn. >>>>>>> More than 16" to complete the read. No OO's. >>>>>>> 2) .num_samps = 3e5. Read 1024 samples each time in a loop adding 1" >>>>>>> to sleep >>>>>>> in each turn (1, 2, 3, 4, ...). 11 hrs to complete the read. No OO's. >>>>>>> >>>>>>> Is overflow even working right? >>>>>>> How large are the streamer's receive buffers? >>>>>>> >>>>>>> Nikos >>>>>>> >>>>>>> On Wed, Jul 30, 2025 at 3:04 PM Nikos Balkanas <nbalka...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am getting a few overflow errors after sometime, from using my >>>>>>>> code.. >>>>>>>> First OOs in stdout and then metadata at which point it stalls. >>>>>>>> I'm using .stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE, >>>>>>>> Each time I read .num_samps in a loop until complete and then >>>>>>>> restart the streamer. >>>>>>>> I can't think of any case that I don't read all of the samples, so >>>>>>>> this shouldn't happen. >>>>>>>> What tools are there to debug this issue? >>>>>>>> A function to monitor the rx_streamer internal buffers would be >>>>>>>> very useful. >>>>>>>> Even the filename that implements this overflow would be helpful. >>>>>>>> Grepping "OO" in the sources doesn't help. Always hits in "BOOST":( >>>>>>>> >>>>>>>> TIA >>>>>>>> Nikos >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>> >>>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>> >>> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com