Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

[Michael Dickens]

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