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
