[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Pipelined processing with the Thread-Per-Block sc
Re: [Discuss-gnuradio] Pipelined processing with the Thread-Per-Block scheduler?
Tue, 9 Nov 2010 12:54:45 -0800
On Tue, Nov 09, 2010 at 04:34:42PM +1100, Balint Seeber wrote:
> Dear all,
> I conducted a simple experiment (using GRC) to test the TPB scheduler's
> performance, and following a search here, I cannot find any definitive
> information that would explain the observed behaviour. I kindly request your
> thoughts on the matter:
> Three flow graphs were created in separate GRC documents. No graph uses
> throttling. Tests were run on a dual-core Linux machine using a 3.3git
> 1) One graph: a high-rate signal source connected to a resampler, which
> is in turn connected to a null sink.
> 2) Two identical disconnected sub-graphs: each contains a high-rate
> signal source connected to a resampler, which is in turn connected to a null
> sink (i.e. as above, just twice).
> 3) One graph: one high-rate signal source whose output is connected to
> the input of two separate resamplers, each of which is connected to its own
> null sink.
> 'High-rate' means a few Msps, and the resamplers output data at a similar
> rate (e.g. 8MHz, decim/interp=4:3).
> Thanks to the TPB scheduler, (2) uses 100% CPU (max load on both cores) as
> the sub-graphs are disconnected.
> However when running (1) and (3), only 50% utilisation is observed. I also
> placed 'Copy' and 'Kludge Copy' blocks before the resampler inputs in (3),
> but this did not increase performance (which makes sense given the assumed
> flow model below).
> I am not aware of the intricacies of the asynchronous flow model used, or
> the TPB scheduler (I only skimmed the source), but I wonder why (1) and (3)
> do not use more than 50% CPU?
What kind of hardware are you running this on? (Pls be specific.)
How may core does the kernel say you have? cat /proc/cpuinfo
If these are i5's or i7's (or anything else with "hyperthreading")
please remember that half of the cores shown by the kernel aren't
really cores, and that there are substantial resources shared between
I've achieved near linear speed up, up to 24 cores, with certain flow
graphs so I'm pretty sure that the implementation is sound.
Feel free to send me the grc file off list and I'll take a look at it.