[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Dickens
Subject: [Discuss-gnuradio] Comments on "BBN's Proposed extensions for data networking"
Date: Wed, 7 Jun 2006 14:09:06 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]