Johnathan Corgan wrote: > On Thu, Dec 11, 2008 at 1:46 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > > Yes. The "thread-per-block" design by Eric allows, in many cases, for > the flowgraph throughput to rise until an individual block consumes > 100% of a single core. This is a great improvement over the > single-threaded scheduler that would rate-limit when an entire > flowgraph of blocks consumed a single core. > > You can switch between the two for comparison: > > $ export GR_SCHEDULER=STS # single-threaded-scheduler (old) > $ export GR_SCHEDULER=TPB # thread-per-block (new, default) > > -Johnathan > > The CPU consumption behavior in my application appears to be that one CPU is biased over the other three by almost 2:1. No single CPU is consuming 100%, but the total CPU consumption of the usrp_ra_receiver.py process hovers around 85-90%.
I'm working on getting a new motherboard with dual-channel RAM capability, and the ability to drive my Q6600 at a higher clock rate. I think what's happening is that the I/O thread is going as fast as it can, but it just isn't fast enough to service the data coming off of the USB. Could it also be that my USB subsystem is just not that good? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
