discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: file_sink and performance monitoring


From: Paul Atreides
Subject: Re: file_sink and performance monitoring
Date: Tue, 31 Aug 2021 17:33:54 -0400

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 <jim.melton@sncorp.com> 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=sncorp.com@gnu.org> On Behalf Of Jeff Long
Sent: Tuesday, August 31, 2021 14:13
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]