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

[Michael Dickens]

On Jun 15, 2006, at 12:51 AM, David Lapsley wrote:
> On 6/14/06 2:24 PM, "Michael Dickens" <address@hidden> wrote:
> > 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?

Sure, you could move them to 4.5.2, so long as they're rephrased as  
"limitations of the current framework" as opposed to "packet-radio  
needs".  Limitations are OK, since they work within the baseline  
concept; packet-radio needs do not work there, since they have  
nothing directly to do with the baseline.

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

Ahhh .... so will there be some "test runs" to get timing  
information, in order to have a better estimate of latencies?  From  
another perspective: How does this info get gathered without any  
estimate of how long it will take and thus how many CPU cycles to  
allow for the gr-flow-graph computation?  Yes, you can surely do what  
you've written ... I'm just wondering how the estimates are initialized.

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

Hmmm ... good point.  In a dynamic system, ports could get dropped or  
connected "on the fly".  Could you write a quick blurp about this,  
somewhere before 4.9?  Maybe 4.6.8 or 4.8.6?