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

[David Lapsley]

Michael Dickens wrote:
> 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

Hi Michael,

Thank you for the comments and discussion.  I've cut out all of the 
comments that I have already incorporated into the document.  See my 
other comments below.

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

This sentence is confusing.  How about the following:

"The Media Access Control (MAC) layer needs low-latency transmission 
control -- faster than the FIFO processing currently implemented in GNU 
Radio flow graphs."?

The main point here is that with m-blocks, a high priority message can 
propagate through an entire set of m-blocks in a very short time by 
"overtaking" lower priority messages that are already queued in the 
m-block buffers along the way.

There are quite a few concepts in this paragraph.  One is that of 
pre-computed data sample buffers.  These are created and then await a 
signal before being transmitted over the air.  The second concept is 
that of low latency propagation of messages through a set of m-blocks 
(e.g. a control signal to transmit a buffer).  The third is the idea of 
using processing latency information to try and manage the scheduling of 
m-blocks in a way that maximizes the chances of meeting timing 
requirements (hopefully, under some circumstances the chances of meeting 
these requirements will be quite high).  Somehow, it didn't come out 
quite as clearly as we had hoped.

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

Here "systolic" is used to describe the "pulsing" movement of the data 
through a flow graph (as in the "systolic" phase of a heart beat when 
blood is pumped from the heart into the arteries).  Is that ok?


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

I believe these two statements are consistent.  The two cases are:

* A generic m-block (no GNU Radio blocks inside it):  in this case, the 

  processing inside the m-block must relinquish control of the processor
  after "quantum" processor cycles.

* An m-block enclosing a GNU Radio flow graph: in this case, the
  enclosing m-block will pass a block of data that should take one
  quantum's worth of processor cycles to pass through the GNU Radio flow
  graph.

In either case, the m-block is relinquishing processor control after one 
quantum's worth of cycles.

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

Yes.  The "gr single threaded scheduler" runs in its own thread.  The 
sequence you suggest should work just fine.

Thanks again for the comments!  I'll send an updated version of the 
document to the list at the end of the week.

Dave.

dlapsley.vcf
Description: Vcard