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 <nbalkanas@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.braun@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 <nbalkanas@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 <nbalkanas@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.braun@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 <nbalkanas@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.braun@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 <nbalkanas@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 <nbalkanas@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-leave@lists.ettus.com >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>>>>> >>>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>>> >>>> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >> >

Hey Nikos,\ \ Sorry to here that you were not successful.\ \ Just for your information, I did just recently(this week) fix a bug that might be related to your issue, that should be part of the upcoming UHD release 4.9.\ \ The bug that was fixed is related to a scenario, where if you use the \`NUM_SAMPS_AND_DONE\` mode for RX streaming, if you are slow in receiving the data on the host, and there is an Overrun(the “O”) on the FPGA side, after the overrun has occured if you try to recv() the rest of the data, the remaining data would have been lost.\ \ This sounds very similar to the problem you are facing, at least if you are using one of the standard bitfiles that includes the DDC block in your RX datapath.\ \ The fix should be available on the UHD master branch soon, probably end of the week or next week, or you can wait either for UHD version 4.9 RC2 for testing if this fixes your issues, or wait until the regular version 4.9 release occurs.\ \ The fix is on the FPGA side, so if you can not wait, and want to add the potential fix to build your own bitfile let me know, and I can provide you with more details.\ \ Regards,\ Niels