Some of the interpolating blocks currently get called every sample at low sample rate, so they end up with a very high CPU utilization. The effect isn't so noticeable at higher rates. I don't think this happens with decimation, though.
Someone was using nitens_read-nitems_written to figure out buffer content. Buffers will tend to be full or just about empty. There's no mechanism that would keep a buffer half full or anything like that. For example, let's say you have one processor-intensive block in the middle of a chain of blocks. All the output buffers up to that block will tend to be full, and all the output buffers from that block on will tend to be empty. Since threads are scheduled by the O/S, which has no insight into the flowgraph, there will be some randomness. On Tue, Aug 31, 2021 at 4:57 PM Jim Melton <[email protected]> wrote: > I’m actually happy that the buffer isn’t full. I’m just surprised that > it’s always empty. > > > > The input is at 8msps. It flows into an interpolation block to decimate to > 2msps. Your comment about interpolation has me thinking. When you say > “hogs” is that scheduler hogging, or just general CPU usage? I’m running on > a very capable box with lots of spare CPU cycles/cores. > > > > Does 0% make sense in this case? > > > > Are there other methods I can/should call to get deeper into the buffer > usage (like absolute number of items in the buffer)? > > --- > > *Jim Melton* > > Principal Software Engineer > > Sierra Nevada Corporation > > > > > > *From:* Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton= > [email protected]> *On Behalf Of *Jeff Long > *Sent:* Tuesday, August 31, 2021 14:13 > *To:* GNURadio Discussion List <[email protected]> > *Subject:* [EXTERNAL] Re: file_sink and performance monitoring > > > > As you noticed, the scheduler currently has some corner cases, and changes > to the flowgraph can affect which blocks see backpressure or starvation. We > recently noticed that interpolators can become hogs even at very low rates > for this reason. > > > > The file sink may benefit from an output multiple. The scheduler does not > allow changing of output multiple in a running flowgraph, so this could > cause output to be truncated to a multiple. There is no guarantee that all > samples make it through a flowgraph at termination, so this may not matter. > The main reason I imagine file sinks affect performance (other than just > adding another block) is that they write to disk. > > > > Yes, you may find blocks where the buffer is never full. This isn't wrong, > and it tells you that that block isn't causing backpressure or seeing it > from downstream blocks. > 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. >
