[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: Number of samples processed in the work function
From: |
Jim Melton |
Subject: |
RE: Re: Number of samples processed in the work function |
Date: |
Tue, 28 Jun 2022 18:07:02 +0000 |
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.