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