[Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"

[Michael Dickens]

Here's the first round of comments from me.  I've read through the  
document a few times, and along with the other discussion am slowly  
putting pieces together.  These commends reflect my current beliefs /  
understandings, and of course are subject to change as I get  
corrected / educated. - MLD

ps> I'm not correcting typos or bad grammar, but I'm am offering  
suggestions for questionable word usage.

* "enhance" doesn't sound right to me; it implies that the -current  
code base- (gnuradio-core) will be changed.  I like "extend" or  
"augment" instead, which are used up-front in 4.1 onward.  There are  
6 instances of "enhance" in some form, and 41 uses of "extension" or  
the like.  I'd change the former to the latter.

1) p52, table 4.1: "an enhanced version of the GNU Radio block" ...

--> The m-block will not inherit from a gr-block.  Hence they are  
separate concepts and implementations, and one has no relationship to  
the other, except that they both belong to the overall GR project.  I  
would say "a new version of the GNU Radio block"

2) p55, 4.5.1, top bullet: "Dynamic reconfiguration is intertwined  
with scheduling and requires support from both the scheduler and  
enhanced blocks."

--> Ditto from above: "both the m-block scheduler and related blocks."

3) p55, 4.6: "plans for enhancing the GNU Radio architecture"

--> "plans for extending the"

4) p60, 4.8.2.2: "Figure 4.4 shows how the enhanced scheduling scheme  
interworks with GNU Radio scheduling."

--> "how the new m-block scheduling scheme interworks with current gr- 
block scheduling"

5) p61, figure 4.4: "Enhanced Flow Graph"

--> "Extended Multi-Level Flow Graph"

6) p61, 4.8.2: "The proposed m-block executes under the control of  
the new enhanced scheduler"

--> "the new scheduler"

* p49, 4.1; p69, 4.11: "can be implemented in an incremental fashion  
on the existing GNU Radio framework and will have no impact on  
existing GNU software or functionality."

1) I would remove the last "GNU", it's redundant and maybe even  
deceptive

2) I would change/add: "... implemented in an incremental fashion as  
separate modules on ..."

* p50, 4.2: "The Media Access Control (MAC) layer needs low-latency  
transmission control - faster than ``just in time'' processing  
through a flow-graph."

--> From a certain perspective, all data processing is JIT: it either  
happens in time, or it doesn't.  If a very complex set of  
computations are specified for m-blocks in the meta-data, then the  
processing might not be in time; there is no guarantee and nothing  
that the m-scheduler could do about it.  I you believe what I just  
wrote (as I do), then this sentence is misleading.  m-blocks will not  
be any faster than gr-blocks, but they will "know" about latency and  
thus can determine if they're "on time" or not.  Or am I mixing  
issues - control signals versus data processing?

* p53, 4.5.1: ``systolic'' ... I don't think what's there makes  
sense, unless there is a new definition online dict's are not aware  
of.  Maybe -> "systematic"?

* p54, Algorithm 1 GNU Radio Scheduling loop.   "while  True  do"

--> This is no longer the case, should read instead something  
equivalent to "d_enabled && nalive > 0"

* p56, 4.6.1: Needs to be filled in, and I would add something  
describing that the proposed extensions are to implemented as modules  
which are independent of the current ones, giving the user the choice  
between the new m-blocks and the current gr-blocks, or combining them  
with the requirement that the m-blocks are primary.

* p56, 4.6.4: "These items are typically floats, doubles or complex  
values."

--> I would rewrite this to state that "These items can be any  
standard C/C++ element, including ints, floats, doubles, complex  
values, and even structs."  Yes, I've done testing on structs and  
it's possible to send those around.  It's easiest when their size is  
"small", but possible no matter their size.

--> I would move this whole paragraph up to 4.5.1 since there are no  
other comparisons between the gr-stuff and m-stuff in 4.6.

* p57, 4.6.4: "A block can have zero or more input streams and zero  
or more output streams."  ... but not both zero input and output  
streams.

* p57, 4.6.5: "The proposed extensions support interoperation between  
GNU Radio blocks and m-block s, reconcile the scheduling of GNU Radio  
flow graphs, m-block s and real-time scheduling."

--> This doesn't make sense yet.  I think it's trying to say  
something like: "The proposed extensions support the needs of time- 
knowledgeable, priority-based scheduling required for processing m- 
blocks, as well as reconcile the interoperation between current GNU  
Radio flow graphs and the new m-blocks."

* p58, 4.8.1: At the end of the first paragraph, I move "An m-block  
may have zero or more bi-directional message ports." to the end, and  
would add something to the effect of "There may be multiple ports of  
the same protocol and ports can be uni-directional if needed."  I  
think it needs to be made clearer up front that there can be lots of  
ports into/from/inside an m-block, and these can be of the same  
protocol as well as bi- or uni-directional  ... that ports are not - 
required- to be bi-directional, but it is an option.

* p59, Figure 4.2: The drawing makes it look like there is an input  
port and an output port for each port type, yet it says "bi- 
directional" which would imply to me that there is a single port  
handling both input and output.  After looking at this a few times, I  
now see what it's meant to describe.  I think it would make sense to  
separate the port name ("Control Messages") from the "bi-directional"  
text.  Put the "bi-directional" part between the "input" and "output"  
blocks, somehow connecting them in such a way that the "bi" part is  
more clear.

* 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."

--> 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.

* p61, 4.8.3: I would move the first part (ending in "signal  
processing blocks") up to 4.5 somewhere.  It really doesn't belong  
here, but it is useful as part of the current GR baseline.

* p65, Figure 4.5 & related reference on p64: It would be -really-  
useful to describe the elements in the Figure ... what the box is  
(the m-block), and the "ports" both conjugated and not (or  
different?).  It would be useful to have 3 different output ports,  
with a brief description of

* p65, 4.9.5: "The conjugation operator swaps the incoming and  
outgoing message sets associated with a protocol class."

--> This is redundant with the previous paragraph; I'd remove it.

* P66, 4.9.7: "decomposition" -> "composition" makes more sense to me.

* p67: Could there be some text about what "C1" and "C2" are, and how  
they are connected to the new m-scheduler?  Are they invoked by the  
encompassing m-block, as part of it's data processing?