Since no one else reported this as a problem, it must be a C-API bug. Seems I'm the only one using it:( I could have fixed it, but since I have more issues with UHD, I opted to write my own C driver for it... bb friends, I'm leaving the group:(
BR Nikos On Fri, Aug 1, 2025 at 5:20 PM Nikos Balkanas <nbalka...@gmail.com> wrote: > 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
