Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks

[Tom Rondeau]

On Mon, Nov 5, 2012 at 5:48 PM, Nowlan, Sean
<address@hidden> wrote:
>>-----Original Message-----
>>From: address@hidden [mailto:address@hidden On Behalf Of Tom Rondeau
>>Sent: Monday, November 05, 2012 5:16 PM
>>To: Nowlan, Sean
>>Cc: address@hidden
>>Subject: Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks
>>
>>On Mon, Nov 5, 2012 at 4:11 PM, Nowlan, Sean <address@hidden> wrote:
>>> How does tag propagation work in these 3 cases? Up until now I've only
>>> been dealing with tags on streams running at the output rate of a USRP
>>> sink. I've stated the assumed answers, but haven't tested...
>>>
>>> 1) gr_sync_block (interpolation by factor L): tag on incoming sample x
>>> will be moved to sample x*L in output stream
>>>
>>>
>>>
>>> 2) gr_sync_block (decimation by factor M): tag on incoming sample x
>>> will be moved to sample FLOOR(x/M) in output stream
>>>
>>>
>>>
>>> 3) gr_block with arbitrary relationship: user has to move tags
>>> him/herself in general_work.
>>>
>>>
>>>
>>> Another question: does the scheduler re-number absolute sample offsets
>>> after every rate-changing block, or does it work backwards from a sink
>>> block all the way to the source block so that absolute offsets are
>>> relative to the output? I can see this getting more hairy when
>>> multiple source and sink blocks are used.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Sean
>>
>>
>>Sean,
>>
>>Yes, you've pretty much got it. All blocks have a relative_rate. For 
>>interpolating blocks (by L), realative_rate=L, decimating by M 
>>relative_rate=1/M. Any other block that >has a rate change should set the 
>>relative_rate.
>>
>>When a tag is moved to a block, the propagation of the tag handles the 
>>changing of the item number based on the relative rate. This happens each 
>>time the tag is >moved between blocks. Since there's no state known about the 
>>rates of any other blocks, we cannot make a call on that when the tag is 
>>actually read or used.
>>
>>There are some tricky blocks that don't have a static relative rate that can 
>>cause problems with this concept. It's for this reason that we created the 
>>TPP_DONT tag >propagation policy. This tells the scheduler not to 
>>automatically pass tags along. In these cases, we expect the block itself to 
>>handle (or not) the proper manipulation of >the tag numbers.
>>
>>Tom
>
> Ok, so the "absolute sample index" at a particular block boundary is really 
> the nitems_written at the output of that block, and there is no absolute 
> index mapping maintained across a chain of blocks?

That's correct. The blocks (actually, the buffers attached to the
blocks) keep track of the item counts. We try to minimize state across
a flowgraph unless it's directly related to the flowgraph operation
itself. We want to keep blocks as independent as possible.

> Thanks for clearing that up! I see in gr_block.cc that the default tag 
> propagation policy is ALL-TO-ALL, and the corresponding behavior in 
> gr_block_executor.cc is that tags are moved according to tag.offset = 
> tag.offset * relative_rate.

Yep, you got it!

Tom