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]
