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

[David Lapsley]

On 6/14/06 2:24 PM, "Michael Dickens" <address@hidden> wrote:

> 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

Michael,

No problems.  Thank you for the great comments!

I'll work on getting your comments into the next revision.  I'll have that
out early next week.

I'd also encourage any other folks on the list to send in their comments
too.  The more the merrier!

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

Do you mean 4.5.2?  The intent here was to describe the current
packet-capabilities in GNU Radio.  The last paragraph could be moved to the
requirements section, but do you think the  whole section should go?

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

Good point.  From the user's point of view, an aggregate m-block enclosing
component m-blocks looks like a single entity, but the aggregation is purely
symbolic, so there is no aggregation w.r.t. The m-scheduler.
 
> * 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.

That's right!

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

Actually no.  This is a mistake.  The transformation could be along a path
through a set of connected m-blocks or through an enclosed GNU Radio
flow_graph. I'll fix it.

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

That's right.  This is also a mistake.  I thought I'd caught all of these,
but have missed a few.  I'll fix that.
 
> 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?

Not much!  This is a bug.  I'll fix it.

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

I think Eric had discussed this earlier.  You are correct that it is not
possible to pre-empt a gr-flow-graph once it has started.  The idea is to
ensure that the amount of data fed into the gr-flow-graph can be processed
within/close to the allowed time.  By making use of the timing information
carried in the m-blocks, it should be possible to estimate the processing
throughput of different gr-flow-graphs and then use this estimate to work
out the maximum amount of data that can be fed into a gr-flow-graph in order
to complete processing within the time budget.
 
> 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).

Hopefully my previous paragraph answers these concerns.  I'll take another
look at this section and see if I can make it a bit clearer.
 
> 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.

You're right.  This is a bug.  The GNU Radio scheduler runs within the
context of the m-block's handle_message() function.
> 
> 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?
 
Sure.

> p75, 4.9.5: Could you make a drawing depicting replicated ports?
> Might add insight for some folks.

OK.

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

It would be possible to prohibit unconnected ports, but there seems to be an
extra degree of freedom including unconnected ports than excluding them.
For example, a port could be initially unconnected, and then connected at a
later stage.

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

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

I think that would be nice.

Thanks again for the comments!

Dave.