For the general scheduler and buffer questions: 1) You can manipulate the max/min buffer sizes on a per block basis in the advanced tab.
2) These are also a good reads and track well with some experiments that I’ve done. https://www.bastibl.net/gnuradio-performance-1/ https://www.bastibl.net/gnuradio-performance-2/ For your specific stream to disk question: Have you set all the standard SDR performance settings on your machine (frequency scaling, power saving, etc) ? Have you tried using a ramdisk instead of physical disk? Is your hard drive an SSD or a spinney? <end transmission> > On Aug 31, 2021, at 16:58, 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 > <[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.
