Re: [Discuss-gnuradio] Question about Cycle Detection in GNU Radio

[Josh Blum]

> 
> The thing is, you don't want your streaming ports to have cycles. It's
> not a fundamental limitation of GNU Radio; it's just not the right
> thing to do. The streaming ports are for streams of data, which tend
> to have strong temporal relationships with each other.
> 

I think Tommy needs to figure out what interface is more applicable for
his purposes: streaming or messaging. Since TCP is involved, its sounds
like blocks will be passing around chunks of memory with length
boundaries. Something message based would be preferable here. But if the
TCP packets are just transporting boundless samples, then a streaming
interface is more applicable. Whatever makes the processing logic most
natural to code in is probably the right answer.

But suppose that a streaming interface is most applicable. Then I
believe that this new router block will cause the stock scheduler to
detect a cycle or loop and *fail*, even though there technically is not
a cycle, since the inputs are unrelated to the outputs. Right?

One way to fix this might be to separate the input ports and the output
ports into two different blocks. This is the trick to keep the stock
scheduler from discovering a loop. However, now with two blocks, you
might face some thread synchronization issues between the two workers,
this can probably be addressed with simple mutexes.

Anywhoo.... point being, if the framework is flexible to all these
options, the user can choose what is best to implement their design.

> Cycles in data streams are (generally; I'm sure there are a few
> exceptions) usually very time-specific. Think of a PLL: if you have
> more than 1 sample delay in your loop, it falls apart as an algorithm
> (I have a paper on this somewhere that shows the math behind how delay
> effects the locking performance). We don't do cycles because we
> transfer large (ideally) chunks of data between blocks. If you're
> processing 8191 items in one work function and try to feed that back,
> you're now that many samples delayed in time. Then next call could be
> a different number. So not only do you have this delay, you have a
> varying time delay. Doesn't make sense for these kinds of streams. And
> if we set N=1 for all calls to work, you're going to maximize the
> scheduler overhead, which is also bad.
> 

Yea, when most people are talking about cycles, they want to implement
something from a DSP text book with feedback to an adder or multiplier.
This is a totally inefficient way to implement the design. The ratio of
scheduler overhead to work overhead is too-damn-high!

But feedback loops are nice to have for academic satisfaction and
simulation purposes. Its really awesome to be able to bring concepts
from basic communications courses to life in GNURadio Companion, with
test signals, sliders, and live FFTs. It was for me anyway :-)

This morning, a few people trying out the advanced scheduler asked me
about using feedback in GRC. You see, getting a feedback loop working is
a matter of preloading the loop with something to set the initial delay,
but there isnt a GRC-friendly way to set the preload on arbitrary
blocks. To keep it simple, I just added an option to the math blocks in
GrExtras, which I think covers most cases:
https://github.com/guruofquality/grextras/issues/36

Cheers,
-Josh