RE: Re: Number of samples processed in the work function

[Jim Melton]

We recently confirmed that set_min_noutput_items() has absolutely no effect on 
processing. The set_output_multiple() is the right way to do what you want. It 
is appropriate because of the conditions you described:
* packets contain a fixed number of samples. 
* you are reading a socket, and not dependent upon an input buffer

You still have an issue if your flowgraph doesn't process data fast enough. You 
would be wise to implement some kind of dropped packet detection and handling. 
For reference, I point you to the UDP packet processor I use, 
https://github.com/CyberRadio/gr-cyberradio/blob/e758c2747e1c32485574458eb7eaac982137b136/gr-CyberRadio/lib/vita_udp_rx_impl.cc#L582
 (there is partial buffer handling in it, because I still thought 
set_min_noutput_items did something when I modified it last)


---
Jim Melton
Sr Principal Software Engineer
Sierra Nevada Corporation
303.566.9582 (o) | 303.862.2459 (m)
jim.melton@sncorp.com | sncorp.com





-----Original Message-----
From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> 
On Behalf Of Marcus Müller
Sent: Tuesday, June 28, 2022 11:19
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: Number of samples processed in the work function

Hi Daniel

On 28.06.22 18:44, Perkins, Daniel (US) wrote:
>   * processing more samples is not recommended

Not only not recommended, it's strictly forbidden, and breaks GNU Radio.
You get only as much output buffer as you get noutput_items. You produce more, 
you're overwriting parts of previous calls' output.
> 
> My socket packets contain a fixed number of samples so to avoid an 
> extra memory transfer, I prefer to copy straight from the socket 
> buffer directly to the output buffer with a volk function.  To make 
> this work, I need to return that number (1024) of samples from the work 
> function which sometimes violates the “processing more samples” rule.

Then your block is broken! This probably only works because you don't notice 
how you're overwriting data that has not yet been processed.

> However, this seems
> to work without any issues and only the occasional dropped UDP frame.  
> I can also manipulate what GNU Radio will assign to noutput_items by calling  
> set_min_noutput_items.

That's the right thing to do.

> When I set the min nouput_items to the size of my payload, I get a bunch of 
> underruns. 
>   What is the optimal way to deal with this?


What happens here is that GNU Radio waits to call your work function until the 
processing downstream has consumed enough items so that there's 1024 or more 
items of space in the output ring buffer.

If that takes longer, on average, than it takes your source to produce these 
samples, you have a problem: You're trying to attach a hamster to a water hose 
and tell it to drink fast enough. No matter how big you make that hamster's 
cheek pouches, at some point the hamster will have to spill some (overflow), if 
it can't drink as fast as the hose pumps in.

So, the solution is to both set min_noutput_items, and to make sure the rest of 
the flowgraph is fast enough so that there's always enough space for your 
work() to write into.

Best regards,
Marcus

PS: I swear, no hamsters were harmed in the making of this email!


CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are 
confidential, may contain proprietary, protected, or export controlled 
information, and are intended for the use of the intended recipients only. Any 
review, reliance, distribution, disclosure, or forwarding of this email and/or 
attachments outside of Sierra Nevada Corporation (SNC) without express written 
approval of the sender, except to the extent required to further properly 
approved SNC business purposes, is strictly prohibited. If you are not the 
intended recipient of this email, please notify the sender immediately, and 
delete all copies without reading, printing, or saving in any manner. --- Thank 
You.