Re: [Discuss-gnuradio] gnuradio dataflow, buffering and scheduling

[West, Nathan]

On Wed, Jul 23, 2014 at 12:37 PM, Anh Duc Nguyen <address@hidden> wrote:
> Thank Vanush,
>
> I have read this presentation already; unfortunately, I found it rather hard
> to draw an overall picture of gnuradio scheduler to some extent of details.
> Perhaps, as Tom said on his webpage
> (http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html)
> the scheduler is the most mysterious and complicated part of gnuradio - not
> easy to digest it
>
> Could you please provide me with some relevant or supplement readings to
> that presentation? I would grateful for it.
> My first intuitive question is that since each signal processing block does
> require both input and output buffers, then it may cause the source-sink
> latency to be significantly large. Is this true and is there any design
> analysis on this?
>
> With best regards,
>
> Nguyen Anh Duc
>

Anh,

There's a very small number of papers that are specifically about the
GNU Radio scheduler. Depending on the level of detail you require the
source code may be the best place (and it helps to be looking at the
flowcharts in the previously mentioned slides).

Second, I'm not sure what your last question is getting at. Each block
has an input and an output buffer, but that buffer is shared with
either the output or the input of a neighboring block. If you believe
that alone is causing a high latency between source and sink then I'm
curious what alternatives you have in mind.

Are you looking only at GNU Radio's scheduler or schedulers in
general? Almohanad Fayez's dissertation, "Design Space Decomposition
for Cognitive and Software Defined Radios" might have some things of
interest in it. He uses KPN to analyze buffer sizes (among other
things). Michael Dickens' dissertation (not about GNU Radio) also has
a pretty good overview of what SDR frameworks are out there and a high
level design approach some notable frameworks take. Between those two
dissertations there's quite a bit of reading and a great way to speed
up on what's out there, especially since they're both fairly recent.

Nathan