1 more detail. OpenCL buffers are created from GPU (= Graphical Processing Unit) memory, that means in my video card. It is mapped in host memory when reading from the streamer. My app sees very clearly this memory, and so should rx_streamer:) I need to check that file.
Nikos On Thu, Jul 31, 2025 at 9: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