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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 -- [email protected] >>>>>> To unsubscribe send an email to [email protected] >>>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> _______________________________________________ >>> USRP-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
