[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data n
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking" |
Date: |
Wed, 7 Jun 2006 23:01:07 -0700 |
User-agent: |
Mutt/1.5.9i |
On Thu, Jun 08, 2006 at 12:38:02AM -0400, David Lapsley wrote:
>
> >* p60, 4.8.1: "In order to support real-time scheduling, a mechanism is
> >required that will allow m-block s to relinquish control of a processor
> >after a certain number of processor cycles have been used (we will refer
> >to this number of processor cycles as the scheduling quantum )." and
> >"The gr single threaded scheduler will run until it walks all the
> >incoming data (one scheduling quantum worth) through the graph to the
> >final sink, at which point it returns."
>
> I believe these two statements are consistent. The two cases are:
>
> * A generic m-block (no GNU Radio blocks inside it): in this case, the
>
> processing inside the m-block must relinquish control of the processor
> after "quantum" processor cycles.
>
> * An m-block enclosing a GNU Radio flow graph: in this case, the
> enclosing m-block will pass a block of data that should take one
> quantum's worth of processor cycles to pass through the GNU Radio flow
> graph.
>
> In either case, the m-block is relinquishing processor control after one
> quantum's worth of cycles.
>
> >--> These seem in conflict with each other. Further, the only obvious
> >reference in 4.8.2 to the relinquishing of control is the "yield()"
> >function. Maybe: The "gr single threaded scheduler" is run in a
> >separate thread from the executing m-block, and the m-block sleeps for a
> >set time (the "scheduling quantum") ... it will wake up if the thread
> >finishes or if the sleep returns, at which point it checks the state of
> >the thread, and either yields to the m-scheduler, or returns the
> >gr-scheduler's data.
>
> Yes. The "gr single threaded scheduler" runs in its own thread. The
> sequence you suggest should work just fine.
Nope. gr_single_threaded_scheduler (or something above it) will be
called from the handle_message callback of the mblock, and thus will
execute on the mblock's thread.
FWIW, I think all this stuff about scheduler quanta is confusing, and
should be deleted. I'm assuming that everything is "run to completion".
If you want a shorter interval until completion, bite off smaller
chunks. I don't think any of this really needs to be in the doc, but
will fall out as an implementation detail.
Eric
- Re: [Discuss-gnuradio] Proposed enhancements for data networking, Michael Dickens, 2006/06/06
- Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking", David Lapsley, 2006/06/08
- Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking",
Eric Blossom <=
- Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking", David Lapsley, 2006/06/08
- Re: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking", David Lapsley, 2006/06/11
- [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Michael Dickens, 2006/06/14
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", David Lapsley, 2006/06/15
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Eric Blossom, 2006/06/15
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Michael Dickens, 2006/06/15
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Eric Blossom, 2006/06/15
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Michael Dickens, 2006/06/16
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", David Lapsley, 2006/06/15
- Re: [Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking", Michael Dickens, 2006/06/15