Dave - Working on v3 of this document. There are some changes from
the previous version which greatly improve clarity! Thanks! Here
are some more suggestions, comments, questions, and thoughts. - MLD
p60, 4.2: "The Media Access Control (MAC) layer needs low-latency
transmission control -- faster than the FIFO processing currently
implemented in GNU Radio flow graphs." : How about just removing the
reference to GNU Radio's flow graphs (or maybe, moving it to the GR
baseline section), since it's the only "comparison" in that whole
paragraph. You can certainly add something else on the tail of that
short sentence, but it needs to be an extension which describes the
"low-latency transmission control". If this concept is solely for
prioritizing messages, then you could make it something like "The
Media Access Control (MAC) layer needs low-latency transmission
control, allowing for high-priority messages to propagate through a
set of m-blocks undisturbed so-as to minimize computational latency."
if you felt that was appropriate. If, for the purposes of your
description, this concept is more than that, then add something
else. Either way, removing the comparison IMHO is useful.
p61, REQ 4.10: I would add the words "the current" to "GR Framework"
to make it explicit what you're not going to change.
p61, REQ 4.13, 4.14: Could these be combined, or 4.14 just removed?
What is the difference, since the latter seems to be a subset of the
former. What are the concepts supposed to be, as they seem
duplicative to me?
p63, 4.5.1; and p70, 4.8.1: It would probably be worth noting that in
the gr-stuff world there is no generic built-in functionality for
stopping computations to allow for higher-priority computations to
take place (even if the gr-scheduler were written to handle
prioritization) [NOTE: it would be possible for individual gr-blocks
to do this, but none at this time do that I know of]. Thus -any- use
of the gr-scheduler must wait until completion of all data being
processed. This goes for m-blocks too when encapsulating a gr-flow-
graph, not just gr_blocks and flow-graphs standing alone.
p64: "systolic": I still feel it just doesn't work. Yes, I read what
you wrote about the "pulsing" nature of the GR scheduler, of which I
agree that's pretty much how it works. But "systolic", at least in
my understanding and def'n reading, means contraction/compression
(specifically of the heart muscles, but could be others) ... the
result of which is the pulsing nature of blood-flow. The pulsing is
a result of the systole, but isn't what the systole does or is. I
still feel that "systematic" or "round robin" or even (arranged,
methodic, orderly, well-ordered, well-regulated) might be better when
used appropriately.
Also, the whole discussion of packet radio requirements doesn't
really fit into the GR baseline, and should instead probably be in
4.3, or at least elsewhere.
p66, 4.6.3: I'd move the second paragraph to the second or third
sentence of the first paragraph ... just fits there better.
* Also, I don't understand "m-block s may be enclosed within a single
m-block and treated as a single entity." down to the flow-graph
stuff From our previous discussion, the aggregation is purely
symbolic in nature ... there is still a virtual, possibly dynamic,
graph upon which the m-scheduler must work. Thus, how can
aggregation make a "single entity" w/r.t. the m-scheduler?
Aggregation implies to me that the primary m-block's "handle_message"
is called, and then that m-block deals with all the aggregated
internal m-blocks (and gr_blocks, if any).
* Regarding: "Primitives will be provided to allow the connection of
internal components of the m-block to each other and to external
interfaces." ... So the m-block class will provide the "graph"
functionality, instead of having it be an external entity as is
currently done in GR? 'tis a good idea, IMHO.
p67, 4.6.4: " transformed by the blocks in the flow graph." --> "any
internal flow graph". I assume you're referring to the gr_block flow-
graph here ...
p67: 4.6.7: which "flow graph" is this referring to? Looks like the
m-block stuff, which isn't a flow graph at all, so I think this needs
to be changed. You might want to do a global search for this term to
make sure all references are appropriate, and change those which are
not.
p68, 4.8.1; and p74, 4.8.4: How can an m-block have zero ports? I
thought that all data / metadata / signals / whatever were
transported via these ports. Without a port of any type, what can an
m-block do?
p68&70, 4.8.1: How can you implement "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" for a gr-flow-
graph and guarantee that the internal flow-graph's memory is
maintained? How is this implemented in general? I guess you could
start a new thread, which would execute for X us or ms, but that
seems like a costly overhead when "real-time" needs very low
latency. You might want to tweak the last paragraph, first sentence,
to state that the gr_single... will run all the data through
regardless of the number of processor cycles it takes, in order to
guarantee memory coherency (or something like that).
p70, 4.8.2.2: "Within an m-block, data is moved through the GNU Radio
flow graph using a GNU Radio scheduler that runs within its own
thread of execution." ... this doesn't sound correct, regarding the
previous discussion.
Also, looks like a new number (or more) is missing, starting with
"However, information ...". Or, well, something is just wrong with
the rest of this section ... seems non-coherent. Could you please
number / reorganize / rewrite / make more coherent?
p75, 4.9.5: Could you make a drawing depicting replicated ports?
Might add insight for some folks.
p76, 4.9.11: "Messages arriving at an unconnected relay port are
discarded." ... while it's nice to have unconnected ports, this
takes extra processing to deal with. Is it possible to never have
unconnected ports, and/or to always make use of all ports? Or in the
dynamic graphing, is this just a possibility which can happen and
thus needs to be considered?
p77, 4.9.11: "These ports are not visible from the outside of the m-
block, and are not a part of the peer interface." ... what does
"visible" mean here? I thought that all m-blocks are dealt with by
the m-scheduler? I think what you're trying to say is that any
internal ports will be defined solely inside the definition of the
enclosing m-block, when using this semi-formal description, and hence
will not be available for connections outside of the enclosing m-
block. Yes?
p77, (4.14-4.16): Would it make more sense to first state that
peer interface = external end ports U relay ports
then go on with the current 4.14 and 4.15 (if desired, or not).
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
