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
