RE: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

[Bob McGwier]

To be completely honest,  I have never understood the gain to us provided by
the COST the single threaded scheduler imposed.  I cannot find the service
the single thread scheduler provides that cannot be done more easily and
with much greater efficiency in the TPB or even before in a simpler worker
thread pool thing but I am sure this is my ignorance.  Of course, it is easy
to criticize when I did not write it and when the author is in the middle of
the Atlantic with a torn sail limping home (take it easy, he was 30 nm from
the end at 7 this morning)!

Well anyway, we are there now with TPB and that is only going to get better.

I would prefer to have enabled and know how to set this in the config file
than to have environment variables alone.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-----Original Message-----
From: Johnathan Corgan [mailto:address@hidden 
Sent: Friday, December 12, 2008 10:49 AM
To: Marcus D. Leech
Cc: Bob McGwier; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

On Thu, Dec 11, 2008 at 1:46 PM, Marcus D. Leech <address@hidden> wrote:

> Also, I looked into the process details of the process running
> usrp_ra_receiver.py, and found that it had
>  25 threads.  That must mean that each block runs in its own thread
> now?

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