|
| From: | Michael Dickens |
| Subject: | Re: [Discuss-gnuradio] Proposed extensions for data networking |
| Date: | Wed, 7 Jun 2006 14:06:21 -0400 |
The "hybrid" enhancements I was thinking of, if they could be made to work, would be integrated into gnuradio-core, not as a separate module as seems to be the case for the m-block stuff. From this discussion, there is no reason that these changes couldn't be added (if desired, and made to work), so long as the gr-mblock (or whatever its name/implementation turns out to be) is updated for any changes, to maintain compatibility between modules. I'll think more about the hybrid model, since Eric has asked some good questions and I obviously haven't been able to communicate my ideas effectively enough, but I'll drop that topic for now in favor of understanding the m-block module better.
I guess my hope was the there would be enhancements to the current scheduler and gr-block to include latency computations, and maybe some other features that would be of interested to any type of data computation mechanism.
I suppose that the easiest way to do this in the future would be to (re)write any gr_block as an m-block in order to have access to these features.
On Jun 7, 2006, at 6:32 AM, Eric Blossom wrote:
I have the feeling that you're not understanding our desire to "wrap" the invocation of a flowgraph.
Yes, I've gotten that "wrap" is a highly desired capability. It allows the modules to be independent of one another, the programming to proceed as necessary on either module, and a host of other desirable properties of which I cannot even think. I agree that, given the current state of gr_block's and gr-scheduler, it makes sense to not touch those any more than necessary .. they're complicated enough as is. Instead, create a new way of doing things - in other words: effectively (re)start from scratch.
No smiley ... hmmm. So how else would m-block and gr-stuff be kept separate if an m-block method is calling gr-scheduler? I'm going back to the desire to keep the programming separate so that m-blocks could be used independent of GR. Ah ... a special block type which "knows" how to execute the gr-scheduler, and does nothing else, yes?That's the basic idea. In any sizable system it's a good idea to reduce the amount of coupling between parts of the system. This leads to a much more maintainable and understandable system. In this case you could imagine 3 modules: gnuradio-core (knows nothing of mblocks) mblock (knows nothing of gnuradio-core) gr-mblock (knows a little bit about both) gr-mblock would probably represent less than 5% of the code in gnuradio-core + mblock, and is the only code that depends on both gnuradio-core and mblock.If not using GR, then that file just isn't compiled. That would be clever, and indeed much better separation of programming than the hybrid model I'm proposing.Yes.The whole point of this exercise is to allow m-blocks to execute GR flow graphs as "subroutines".Why require m-blocks be the place where gr-graphs are called from?First off, nobody is forced to use the m-block stuff. All the old stuff will continue to work just as it does now. That's part of the reason for the strict separation.
Ahhh .... now I think I'm understanding better. The m-block stuff is much like the USRP ... knows nothing of GNU Radio, works independently of GR, but is a module in the same way that gr-usrp and gr-audio-xxx are. The programming is entirely separate for the m- block module, can operate separately from the current GR, much like the USRP module can. gr-mblock would be the "glue" understanding how to operate gr-block's inside an m-block, and hence requires the gnuradio-core libraries and headers for functionality.
Does the mblock module require knowledge of the USRP? Or will there be a mb-usrp module to handle that set of data transfers, much like there is a gr-usrp module for handling gr-block data transfers.
I assume (from other outside discussions) that all of this programming is being added to the overall GR project? Hence the term "enhancements" in the proposal?
In essence, GR was picked as a (the most) promising starting platform (for whatever reason) to receive these new modules. In a sense, the extensions are a gift back to the GR project for being picked? Please don't read this as complaining: Not that I'm complaining, since I think GR will be a much more robust platform with the extensions. I have volunteered to help out in the implementation in whatever capacity I can ... I really believe in the proposed extensions ... I'm just trying to understand how it all works and even some of the background on how it came to be.
Am I understanding correctly that the m-scheduler will basically do the same thing that the gr-scheduler does: it'll provide both an input and output packet reference to the called m-block, which will do processing, filling up the output packet as it goes?Not exactly. The handle_message callback of an m-block is invoked by the m-block scheduler passing a message. There is no "output packet reference". The callback is free to do whatever it likes. It may ignore the incoming message. It may create and send any number of messages to any port that is visible to it. Some of the messages may be very small -- just the "signal" -- e.g., "Reset". Others may have substantial payloads -- a variable length number of bytes that's to be turned into samples. Recall also that the message ports are bidirectional.
So an mblock is provided with the packet and other meta-data to use as it sees fit. As the message makes its way through the m-block's connections / ports, the data is transformed / processed / parsed / etc... (see 4.8.4). There is no explicit "output" port(s), but rather these bi-directional ports which could be used as input-only or output-only. The data is transformed by creating new messages to pass around?
4.8.3: "• requires persistence as the message is processed by the radio• may contain elements that change as the message is processed in the radio."
If I read this, w/r.t. your comments before, then some messages must be kept around as they are processed (creating other messages, which also might need to be kept around: "persistence"), while others can have their internals changed during processing.
Also: An m-block can "contain" other m-blocks internally, or at least that's what I now believe. How are those internal m-blocks scheduled? Is there an internal "m-scheduler" which calls them in their correct order? Or does the encompassing m-block just "know" to call them in order and deals with this itself? Or some other way?
Note that in the BBN proposal there are no "graphs". There are only mblocks, some of which contain other mblocks.
Ok, yes, a semantic difference really. mblocks can be connected to other mblocks, internally and/or externally. Those connections must be checked somehow, whether the terminology is "graph" or "connection" or whatever. It must be verified that the connecting bi- directional ports are compatible (see 4.9.5 for that definition).
So in 4.8.4 what is the "flow graph" as mentioned: "As a message makes its way through a flow graph, the data is transformed by the blocks along the way." Since this is generic, I don't think it applies specifically to the current gr_blocks and related flow- graph. If there is no m-graph, then those "flow-graph" references should be changed.
| [Prev in Thread] | Current Thread | [Next in Thread] |