On Sep 22, 2011, at 1:00 PM, Nick F. 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