[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base file
Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files
Sun, 6 Jan 2019 14:00:38 -0800
thanks for the feedback. For your comments on the block executor, that's a great point -- where does it belong? At some point, we'll need owners for this task. Would you be interested in participating?
I have been looking at the GNURadio scheduler quite a bit recently and
would like to summarize my experiences that could affect the direction
of this GREP. As you have properly observed, the scheduler is very
hard to change as it is, but there are new opportunities if we allow
changes. There are two components: scheduler itself (the scheduler_tpb
and tpb_thread_body) and the block executor. I think both needs some
attention, but it is not clear if you want to address only the
scheduler itself or together with the executor.
- For the scheduler I would really like to introduce a type of
scheduler that manages only a subset of blocks for minimizing latency
by draining internal buffers within this group of block before new
data is accepted into these blocks. Think of a long sequence of blocks
processing packets that we would like to perform one after the other
without bringing all that functionality into a single block. Maybe the
flow graph need not be flattened completely, but certain hierarchical
blocks could be managed by their own scheduler (so flattened into a
level 1 hierarchy). Maybe the single threaded scheduler is just a
special case of this.
- Certain tasks, such as combining packets into frames, might need to
know if future packets are arriving. This can be accomplished with a
timeout, so the block would be notified to flush its internal buffers
if the work function has not been called for a predefined time. There
is no such functionality within the current scheduler and I think it
would be possible to implement one by exposing the timeout used within
- The block executor is also a very complex beast. I am wondering why
the functionality of the executor not implemented within the
basic_block where it could be overloaded.
Hope this starts the discussion and others can voice their opinion.
On Thu, Dec 27, 2018 at 10:58 PM Martin Braun <address@hidden> wrote:
> Hi all,
> final GREP of the day: https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md
> This is possible the most fundamental and influential GREPs that were added so far. I would find it hard to find any reasons not to do this -- of course, the question remains, who will do it. Any takers? I'm hoping that by separating scheduler from base, we can open up the avenue for more and better research into scheduling, as well as custom scheduler development.
> -- Martin
> Discuss-gnuradio mailing list
Discuss-gnuradio mailing list