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.
begin:vcard
fn:David Lapsley
n:Lapsley;David
org:BBN Technologies;Internetworking Technologies
adr:;;10 Moulton St;Cambridge;MA;02138;USA
email;internet:[EMAIL PROTECTED]
title:Network Scientist
tel;work:6178733399
tel;cell:9783971868
x-mozilla-html:FALSE
url:http://www.bbn.com
version:2.1
end:vcard
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
