Michael,
Good description of the TPB running mechanism!
Here is a more detailed explanation with some graph illustrations (see
page 2 of the linked paper):
http://gnuradio.org/redmine/attachments/download/264
Andrew
On 09/23/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:
Message: 6
Date: Thu, 22 Sep 2011 15:52:17 -0400
From: Michael Dickens<m...@alum.mit.edu>
To: Nick Foster<n...@ettus.com>
Cc: Achilleas Anastasopoulos<anas...@umich.edu>,
discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC
graphs
Message-ID:<1fc1f942-d97c-49c9-9a05-bd38f250b...@alum.mit.edu>
Content-Type: text/plain; charset=us-ascii
On Sep 22, 2011, at 1:00 PM, Nick Foster wrote:
> Well, in answer to question 1, you don't need a throttle to avoid system
instability. You really use the throttle to keep your computer from becoming
entirely unresponsive when you have multiple threads with high priority running
simultaneously as fast as they can
That would make an interesting test for Achilleas: Do test 1 using real-time
priority& see if that locks up the system or not.
> I don't know the answer to question 2 -- I suspect to find the answer you're
going to have to do some deep hunting in the scheduler.
Let me see if I can work anything out:
Roughly: In the TPB model when "progress is made" for a given block (e.g., data is generated or
consumed), the appropriate thread(s) containing adjacent blocks are signaled (IIRC, from waiting on a
condition)(e.g., if data is consumed then the prior block(s) [those generating the data] are notified). When
those threads wake up, they check to see whether or not they have enough input data and output space to do
processing. This check is done by the TPB "scheduler" -- it's an algorithm that you can read about
in "gnuradio-core/src/lib/runtime/gr_block_executor.cc" if you really want to. A given block
cannot do processing until enough input data and output space area simultaneously available, and the TPB
scheduler tries to maximize data processing.
For case #1, the signaling and scheduler's job is simple because each block is
connected only to adjacent blocks. If you were to plot out the block execution
pattern, I'd guess it was something like:
(source == 1; sink == 2; E == "executing"; W == "waiting"):
Thread Time ->
1 E E E E E ...
A W E E E E ...
2 W W E E E ...
For this case data is well-pipelined -- A can process as soon as 1 is finished, and
2 can process as soon as A is finished. Assuming A is CPU intensive& the
graph isn't otherwise throttled, then each block could easily saturate a single CPU
(if that's how much processing each requires).
For case #2, the signaling and scheduler's job is complicated by the dual paths
from source to sink. If you were to plot out the block execution pattern, I'd
guess it was something like:
(X == "waiting, unsuccessful execution, and then more waiting"; I switch from "W" to
"X" because of the signaling between threads):
Thread Time ->
1 E E X E E X E E ...
A W E E X E E X E ...
2 W X E X X E X X ...
So, in this case because of the odd data shuffling, you'll see somewhat less than full
CPU usage (on the average). The above "diagram" assumes that 1 is generating a
sizable chunk of data (relative to the total buffer size), such that it can do one or two
writes before its output buffer is full (that's roughly how the TPB scheduler works,
btw). The actual wait time-duration I think depends primarily on how long it takes A to
do processing. Either way: The basic idea is that the data is not well-pipelined, and
hence there are waits that reduce the average CPU usage [another possible factor is how
much overhead time is spent during X's (emerging from wait, checking for processing, then
going back into wait)].
I hope this is reasonably accurate, makes sense, and helps! - MLD
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
