GNU Radio 1.3.1 and SMP

Hi,

Quite some time ago, there are multi core scheduler testing branch for
GNU Radio.

http://lists.gnu.org/archive/html/discuss-gnuradio/2008-07/msg00159.html

Can I do the same with GNU Radio release 3.1.3 and follow the same
instructions mentioned in that mail ? I have actually done that but it
does not seem to distribute the processing among the core on the Intel
Atom 330 motherboard.

Regards,
Hew

Hew How Chee wrote:


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Can you actually see the four threads (two hyperthread cores) in the
linux listing (/proc/cpuinfo). Do you have SMP and HT enabled in the
BIOS?

Bob

Hi Bob,

cat /proc/cpuinfo give 4 processors.

Did more test on running the same piece of code, which is basically a
modified fm receiver. Usually I see nearly 100% loading on 1 of the 4
processors . But sometimes the load is spread on other processor (e.g.
100% load become 50% load on processor1 and 50% on proccessor2). Is this
random behaviour expected ? I was hoping that I can assign gr block to a
processor specifically so that the load is really well distributed.
Forgive me if this question is obvious as I did not track gnuradio
progress as frequently as I would like to.

Hew

On Sun, Mar 15, 2009 at 03:25:28AM -0700, Hew How Chee wrote:

I can assign gr block to a processor specifically so that the load
is really well distributed. Forgive me if this question is obvious
as I did not track gnuradio progress as frequently as I would like
to.

Hew

Hew,

The “thread-per-block” scheduler has been in the trunk for about 6 or
9 months and is enabled by default. It was not included in the 3.1.3
release. It will be in the 3.2 release.

With the thread-per-block scheduler, all SMP/SMT/multicore resources
are automatically used. There is no need (or advantage) in assigning
blocks to particular cores.

Eric

Hi Eric,

Thanks for the info. Will be looking forward to release 3.2.

Best regards,
Hew

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs