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

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 <nbalkanas@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 > >

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 <nbalkanas@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 <nbalkanas@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-leave@lists.ettus.com >

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

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

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

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

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 <nbalkanas@gmail.com> 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 <martin.braun@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 <nbalkanas@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.braun@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 <nbalkanas@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 <nbalkanas@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-leave@lists.ettus.com >>>>> >>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>> >>> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >> >

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 <nbalkanas@gmail.com> 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 <nbalkanas@gmail.com> > 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 <martin.braun@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 <nbalkanas@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.braun@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 <nbalkanas@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 <nbalkanas@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-leave@lists.ettus.com >>>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>>> >>>> _______________________________________________ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>> >>

I'm receiving the correct signal and number of items received. But the buffer is not freed. After ~25 MBs I start getting OOs, until it stalls. GDB shows that it skips uhd code updating the pointer in the source buffer. That's bad:( Nikos On Fri, Aug 1, 2025 at 3:32 PM Martin Braun <martin.braun@ettus.com> wrote: > 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 <nbalkanas@gmail.com> 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 <nbalkanas@gmail.com> >> 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 <martin.braun@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 <nbalkanas@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.braun@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 <nbalkanas@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 <nbalkanas@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-leave@lists.ettus.com >>>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>>>> >>>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>> >>> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >