# Gnuradio dataflow, buffering and scheduling **URL:** \ **Category:** GNU Radio\ **Created:** [July 22, 2014, 6:34pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128 "2014-07-22T18:34:37Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [July 22, 2014, 6:34pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/1 "2014-07-22T18:34:37Z")
Dear all, I wish to study how gnuradio handles the dataflow,e.g., buffering, scheduling, synchronization, optimization as well as resultant latency in detail. However, I can not find any material that explain such things clearly. Could you please point me to direct or indirect resources e.g., in literature which present I need. I would appreciate it much, With best regards, Nguyen Anh Duc ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 23, 2014, 5:10am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/2 "2014-07-23T05:10:45Z")
[http://www.trondeau.com/storage/tutorial/gr\_scheduler\_overview.pdf](http://www.trondeau.com/storage/tutorial/gr_scheduler_overview.pdf) ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 23, 2014, 6:57pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/3 "2014-07-23T18:57:08Z")
On Wed, Jul 23, 2014 at 12:37 PM, Anh Duc N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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 F.‘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 D.’ 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 ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 23, 2014, 6:39pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/4 "2014-07-23T18:39:06Z")
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 ( [Explaining the GNU Radio Scheduler — Rondeau Research](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 ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 12:23am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/5 "2014-07-25T00:23:48Z")
Anh, On Wed, Jul 23, 2014 at 8:22 PM, Anh Duc N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > It should be better if there are some references to guide us through the > complicated codes such as the one Tom wrote, hopefully, there should be > more similar presentations/documents like that. As part of my GSoC I’m working on such a guide as I need to make changes to the GNU Radio buffer management system. I started a wiki page about 2 weeks ago detailing some of my findings and it may help you out. It is incomplete but feedback is much appreciated as it will help me write the page better. [http://gnuradio.org/redmine/projects/gnuradio/wiki/runtime](http://gnuradio.org/redmine/projects/gnuradio/wiki/runtime) ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 24, 2014, 10:29pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/6 "2014-07-24T22:29:00Z")
Thank Nathan and Marcus, Yes, as you said the source code should be the best place to study the details. However, as you may experience, it is fairly challenging to just look at the code, analyze, and make connections among stuffs. It should be better if there are some references to guide us through the complicated codes such as the one Tom wrote, hopefully, there should be more similar presentations/documents like that. With that references, I believe we can have got how gnuradio works more comprehensively and more rapidly. I also agree it is not easy to describe the scheduler in a short, simple, but pretty in-depth ways; then I have asked for just some supplement readings Thank Nathan for your recommended two dissertations, I have just given them a quick look, and they appear to satisfy my desire. I also thank Marcus for key points and trends in the gnuradio scheduler and your frank suggestions how to approach the problems. To be honest, I am studying software structures/platform for software defined radio (SDR), of which, the scheduler is one of the most crucial that I wish to analyze in detail; and in turn, gnuradio scheduler for sure draws much of my attention due to it success and popularity. I hope I could receive more support and help from you all With best regards, Nguyen Anh Duc On Thu, Jul 24, 2014 at 12:51 AM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 2:02am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/7 "2014-07-25T02:02:30Z")
Hi! On 24.07.2014 05:22, Anh Duc N. wrote: > To be honest, I am studying software structures/platform for software > defined radio (SDR), of which, the scheduler is one of the most crucial > that I wish to analyze in detail; and in turn, gnuradio scheduler for sure > draws much of my attention due to it success and popularity. I hope I could > receive more support and help from you all > That sounds really interesting! I think there will be lots of interest > in that, so keep the questions coming 🙂 Greetings, Marcus ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 9:01am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/8 "2014-07-25T09:01:04Z")
On Thu, Jul 24, 2014 at 2:56 AM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > That sounds really interesting! I think there will be lots of interest in > that, so keep the questions coming 🙂 > > Greetings, > Marcus It does sound interesting, and Nathan W. pointed out a good place to start researching this. I agree with Marcus to keep the questions coming. However, I would add that it would be better served for all of us here if you had very focused questions that we could talk about. Open ended questions like “how does the scheduler work” would require a lot of time to construct an answer; time that very few of us have. But a conversation like this done with the right questions could eventually turn into a nice set of discussion topics that could then be turned into something more substantive for others looking at the same questions. Tom ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 9:26am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/9 "2014-07-25T09:26:20Z")
Hello everyone, I’ve been asking the same questions as Anh, since we have a PhD student working on dataflow programming, specifically for GNU Radio. I think this discussion can benefit a lot of people who work with dataflow, but also the rest of us, who just want to understand what’s going on under the hood. Maybe, one day we can compile all questions and answers into a nice formatted document that will serve as a reference for the rest of us… 🙂 Best regards, Leo Leonardo S. Cardoso removed\_email\_address@domain.invalid ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 11:08am UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/10 "2014-07-25T11:08:18Z")
Hello all, Yeah, I also think this topic is interesting to find out this vague and unclear scheduler! I’m waiting for further discussions. Best, Mostafa On Thu, Jul 24, 2014 at 5:50 PM, Leonardo S. Cardoso [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Anh\_Duc\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/85e7bf/32.png) [@Anh\_Duc\_N](https://www.ruby-forum.com/u/Anh_Duc_N)\ **Post date:** [July 25, 2014, 12:31pm UTC](https://www.ruby-forum.com/t/gnuradio-dataflow-buffering-and-scheduling/231128/11 "2014-07-25T12:31:40Z")
On Thu, Jul 24, 2014 at 12:02 PM, Mostafa A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > formatted document that will serve as a reference for the rest of us… 🙂 > > > > Best regards, > > > > Leo > > > > Leonardo S. Cardoso > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) This seems like a good opportunity to plug the working groups and upcoming conference. For information on the working groups: [http://gnuradio.org/redmine/projects/gnuradio/wiki/WorkingGroups](http://gnuradio.org/redmine/projects/gnuradio/wiki/WorkingGroups) . The embedded and especially coprocessor working groups should be interesting to anyone interested in dataflow problems. For information on the conference: [GNU Radio Conference 2014 — Rondeau Research](http://www.trondeau.com/grcon14) . Several presentations will be covering distributed scheduling, coprocessors, and generic dataflow scheduling with an obvious emphasis on SDR and GNU Radio. The working group sessions should also be a good time to share ideas and learn from others while getting a sense of what others are working on. Nathan