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

Reply via email to