[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    RE:  Re: Number of samples processed in the work function
From:       Jim Melton <jim.melton () sncorp ! com>
Date:       2022-06-28 18:07:02
Message-ID: db03538c7d374f59aadbebb3e6a7cb24 () sncorp ! com
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]