Re: [Discuss-gnuradio] Mblocks

[Eric Blossom]

On Tue, Mar 27, 2007 at 12:29:13PM +0200, COLSON Nicolas RD-TECH-GRE wrote:
> Thanks for the answer.
>
> Would it be possible to have a look at the status report on what's
> done and what's left to be done for m-blocks. We may consider
> contributing to the code.

Thanks!  See below.

> We are particularly interested in:
> - the metadata exchange for sending reconfiguration orders

This should fall out naturally.  Each message contains a data and a
metadata attribute.  The interpretation of the data and metadata is up
to you.  You are also free to create, delete, connect and disconnect
mblocks at runtime.

> - the interface with gr-blocks for using previously build modules 

See my message from yesterday.  There will be a subclass of mblock
that knows how to embedded a flowgraph within an mblock, and will
provide a means for sending and receiving data between the mblock and
the flow graph.

> - an effective scheduler capable of assuring on the fly
> reconfiguration withouth data interruption

With regard to mblocks, this won't be a problem.  Johnathan Corgan is
currently working on this feature for classic GNU Radio blocks.  He
and I are scheduled to talk about this later today.  Most of the work
is already done.


Here's what's left to do with mblocks (first pass):

(1) Implement a "thread per mblock" scheduler.  This allows mblocks to
fully exploit SMP/SMT machines, and allows mblocks to block for i/o
while handling messages (it also simplifies the implementation.)  
I expect to have this finished by the end of this week.

(2) Locking on traversal and modification of the internal data
structure that describes the mblock interconnections.  I expect to
have this finished by the end of this week.

When (1) and (2) are complete the foundation of the system is basically
working.

(3) Define interface for supporting timer messages, and implement the
mechanism.  That is, provide a way for mblocks to have one-time or
periodic Timeout messages sent to them.

(4) Create a tool (script) that compiles protocol class definitions
into C++ code.

(5) Cache the resolution of connections between mblocks.  The code
will work without this, but caching the location of the ultimate
recipient of a message allows us to remove lots of runtime overhead
from the "send" primitive.

(6) syntactic sugar for connect / disconnect.  Allow the connection to
be expressed as a single string, e.g. connect("self:control to transmitter:cs")

(7) Implement serialize and deserialize (marshalling) for pmt objects.
This will allow them to be passed across process or machine boundaries.

(8) Write a couple of example applications.

(9) Create a subclass of mblock that knows how to embed a flow graph.
Create the associated sinks and sources.  Write an example that uses these.

(10) Document the differences between what's implemented and the BBN paper.

In addition to the mblock basics these things remain:

  * inband signaling for USRP (design currently in progress)

  * Consider revising the mblock composition API such that it is more
    declarative than functional.  This could facilitate configuring
    and running a system of mblocks across a cluster or other h/w that
    lacks shared memory between processing elements.

  * Consider implementing pmt data types in a shared memory segment
    with appropriate thread-safe reference counting.  This would allow
    very fast exchange of (large) messages on SMP/SMT machines.


I'm sure I've left things out...

Eric

> -----Message d'origine-----
> De : address@hidden [mailto:address@hidden De la part de Greg Troxel
> Envoyé : vendredi 23 mars 2007 14:17
> À : EVENNOU Frederic RD-TECH-GRE
> Cc : address@hidden
> Objet : Re: [Discuss-gnuradio] Mblocks
> 
> 
> "EVENNOU Frederic RD-TECH-GRE" <address@hidden>
> writes:
> 
> > I  am currently developping a cognitive radio demonstration system 
> > under the GNU Radio Platform and I am particularly interested in the 
> > mblocks extension proposed by the ADROIT Project. Reading the 
> > available documentation and looking to the source code, I realized 
> > that the extension is still a work in progress and I would like to 
> > know if mblocks are already available as a base class for deriving my 
> > own signal processing blocks.
> 
> The code that is there is there and you're welcome to start hacking, but 
> you'd be the first user - there aren't examples already in the tree, which is 
> a sign that this won't (yet) be that easy.
> 
> > Inspecting the mblock directory, I've noticed that there are no .i 
> > files nor .py so the extension seems unavailable as a Python module. 
> > Consequently, I would like to ask you some questions:
> >  - Is the current mblock directory exploitable and bug proof?
> 
> Certainly not - and probably the rest of the code isn't.  I'm not sure what 
> you're really getting at.  Most of GNU Radio seems to run pretty reliably, 
> but your using 'proof' makes me wonder about your requirements.
> 
> >  - May I use it as a base class for deriving my own signal processing 
> > blocks?
> 
> You may, but you will surely have to dig in and really understand what's 
> going on, and supply some missing pieces.
> 
> >  - If I create an interface file for the mblock extension and if I 
> > generate all other files (.so, .py, .o ...), will I be able to 
> > interface my own module with Python?
> 
> Yes, but be warned that this is likely considerable work.
> 
> Sorry if I'm sounding like I'm just telling you that you need to read and 
> understand all the code that's already present, and that sure you can do all 
> of it but it's a lot of work, but that's how I see it.
> Contributions of code are always welcome (FSF assignment required as for all 
> GNU projects).
> 
> > For your information, this project is part of a PhD thesis at France 
> > Telecom R&D (French telecommunications company) focusing on 
> > integrating cognitive mechanisms into radios.
> >  
> > Thank you in advance for your answer (and for the work done with this 
> > extension, particularly attractive for cognitive applications).
> 
> Perhaps Eric can give a status report on what's done and what's left to be 
> done for m-blocks.
> 
>     Greg Troxel <address@hidden>