Miklos, 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?
-- M On Wed, Jan 2, 2019 at 5:54 PM Miklos Maroti <mmar...@gmail.com> wrote: > Dear Martin, > > 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 > tpb_thread_body. > > - 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. > > Best, > Miklos > > On Thu, Dec 27, 2018 at 10:58 PM Martin Braun <mar...@gnuradio.org> 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. > > > > Discuss! > > > > -- Martin > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
