Announcing new scheduler for GNU Radio

GNU Radio
1

Hey folks,

I have been working on a new scheduler for GNU Radio, called the GNU
Radio Advanced Scheduler (GRAS). GRAS is a complete re-write and
overhaul of the stock GNU Radio scheduler to implement new features,
performance enhancements, and a simplified user API. A new buffer and
threading model gives GRAS zero copy features, allowing integration of
DMA devices and seamless transition between stream and packet domains.
Here is the main project wiki page:

Each feature has a mini-description on the Summary wiki with a link to
greater detail and code examples. I think there is something in this
project for everyone; whether you are into API design, models of
computation, concurrency mechanisms, zero-copy, data flow topology…

Nobody gives a lick about features without the horsepower! I have
benchmarks on two PC variants: operton and i7. I am happy to report that
the features do indeed offer performance benefits, and that GRAS is up
to the challenge. The operton benchmarks look great, however I would
like to see better results on the i7.

Behind all of the GRAS fluff, the Theron C++ concurrency library is the
real scheduler; driving all of the work dispatching, threading, and
synchronization. I have to give a special thanks to Ashton Mason for
creating the Theron library. Both Theron and Ashton were a pleasure to
work with.

Whats next/whats in the queue for GRAS?

Characterization. I need to run the benchmark suite on more platforms to
get a better idea about how design decisions and trade-offs affect the
performance. And I will try to optimize some of the more troubled
benchmarks.

GR Wrapper. The current wrapper that makes the GNU Radio blocks work on
top of GRAS has seen a lot of development history. I plan to rewrite
this wrapper to be slimmer and to reuse as much code as possible; much
like the style of the new gnuradio-runtime component.

Theron. A new version of Theron (v6) is in the works, with runtime
selectable schedulers for different synchronization schemes, backoff
mechanisms, and work dispatching optimizations. My hope is that this
capability will allow users to easily optimize their applications for a
particular architecture.

Phew, that was a wordy email! Thoughts, feedback?

-josh

2

Hi,

thanks Josh for this email, it’s a great source of information! Let me
ask
a couple of questions: Will GRAS be included in the GNU Radio 3.7
release?
Will users be able to select what scheduler they want to use (the
current
one or GRAS), or is GRAS going to replace the current scheduler?

Best regards,
Carles

3

On 04/17/2013 04:26 AM, Josh B. wrote:

Behind all of the GRAS fluff, the Theron C++ concurrency library is the
real scheduler; driving all of the work dispatching, threading, and
synchronization. I have to give a special thanks to Ashton Mason for
creating the Theron library. Both Theron and Ashton were a pleasure to
work with.

http://www.theron-library.com/

I dislike projects that force you to enter an email address to download
the source and do not provide access to the project SCM. It makes
automated builds very difficult.

Philip

4

On 04/17/2013 09:51 AM, Phil Frost wrote:

GitHub - guruofquality/Theron: concurrency library for C++

Heh, looks like he also addresses the problem of the broken build system
in Theron. People that right their own makefiles should be shot :slight_smile:

Philip

5

If it isn’t broken makefiles, it’s broken meta-make files (whether
it’s autotools, or Cmake), or broken meta-meta-makefiles.

The buck
eventually, inevitably, stops at the huminz…

On 17 Apr 2013 10:03,
Philip B. wrote:

Heh, looks like he also addresses the problem
of the broken build system
in Theron. People that right their own
makefiles should be shot :slight_smile:

6

On 04/17/2013 09:45 AM, Philip B. wrote:

On 04/17/2013 04:26 AM, Josh B. wrote:

Behind all of the GRAS fluff, the Theron C++ concurrency library is the
real scheduler.

I dislike projects that force you to enter an email address to download
the source and do not provide access to the project SCM. It makes
automated builds very difficult.

Looks like Josh has already solved that problem:

7

On 04/17/2013 04:35 AM, Carles Fernandez wrote:

Hi,

thanks Josh for this email, it’s a great source of information! Let me ask
a couple of questions: Will GRAS be included in the GNU Radio 3.7 release?

Hey, thanks for the response. I guess I gave the wrong impression. GRAS
is definitely still in the beta stage, it doesn’t even have a version
number yet, and needs a lot more field testing.

This email was more of a formal announcement of the work so people could
try it out and I could get feedback. Its certainly not ready in any way
to be part of a formal release.

Will users be able to select what scheduler they want to use (the current
one or GRAS), or is GRAS going to replace the current scheduler?

Perhaps one day it could be come a compile time option just like the
single and thread per block scheduler. But, GRAS has a lot of work to
prove itself. And the decision to include the work is really up to the
GNU Radio devs and not me.

I hope that clarifies things!

-josh