TagsTaskForce

= TagsTaskForce =

The tags efforts have currently been folded back into the FASS Working Group.

Things we want to think about regarding tags, messages and tagged stream blocks:


 * Tagged stream blocks: Currently are hacked ontop of regular streaming API
 * Tags: Might not be implemented in the best way possible (storage format, CPU cost...)
 * Messages: Back-pressure? (i.e. post blocks)?

= Tag handling =


 * It would be great to register tag propagation mechanisms, per-block, maybe even per-tag-key
 * There are tag propagation problems with the PFB arbitrary resampler (see issue #652). Other blocks with noninteger relative rates could also have the same types of problems.
 * Tag propagation with noninteger relative rates could break the continuity of a stream of tagged streams, i.e, offsets and packet lengths could be nonconsecutive. This would break UHD's length_tag implementation (see issue #530).

= Tagged stream blocks =


 * Allow fragmented mode?
 * Mustn't break backwards compat
 * What would fragment sizes be? As large as possible, or whatever's available?
 * Right now, the return value of tagged_stream_block::work is used for both consume/produce as well as the creation of the new length tag value -&gt; wouldn't work
 * How would we know we're in the last fragment or not? -&gt; Don't want to change work signature

= Performance Comparison of burst approaches =


 * Should we be building message passing blocks? tagged stream blocks? or something else?
 * It's probably worth us building a few test cases and measuring performance between the two - then talking about what kinds of performance improvements we can make to message passing, PMTs, block buffer changes, tagged stream blocks, etc.

= Minutes task force meeting March '14 =

Minutes tag discussion:

- PDUs and tagged streams are both here to stay, and we don't plan to change that anytime soon - Tim: Will try to implement a non-invasive way to register handlers to TSBs s.t. they can rx/tx PDUs - Policy change for 3.8: Any submissions must split work kernel from actual block implementation (Tom, can you put something on the wiki and remember to enforce that when 3.8 comes close =&gt; pfb_resampler as example) - Hopefully all of this will reduce duplication, and create an environment where PDU blocks and TSBs can peacefully and happily coexist - The UHD sink will take Sean's merges, this includes - Ability to handle non-contiguous TS's by outputting characters (see below) - General ability to handle length tags instead of sob/eob - Nick points out that our current length tag implementation is redundant, and is inviting trouble. It would be enough to mark the end of tags -&gt; This will be investigated for maybe 3.8 - Sean will be task force leader for tags- and TSB-related stuff

- We didn't really go into detail about the actual changes needed to be done to TSBs, apart from end-tags. Fragmentation might be necessary.

More inline:

On 03/26/2014 07:52 PM, Nowlan, Sean wrote: &gt; A couple of ideas for the characters to print out if tagged streams are &gt; cut short or there is a gap between them: &gt; &gt; Tag interruption/preemption/overrun: “tI” or “tP” or “tO” &gt; &gt; Tag discontinuity/gap/underrun: “tD” or “tG” or “tU” &gt; &gt; Thoughts? “tO” and “tU” are more consistent with UHD, audio sink/source, &gt; and gr-osmosdr sink/source conventions, but I’m not sure they are &gt; accurate. Also since this will be coming from usrp_sink, I don’t want &gt; the characters to be confused with the UHD messages. I like “tP” and &gt; “tD” or “tP” and “tG”. “tI” could be hard to read since the letter “I” &gt; looks like a numeral one and a lower case l.

I think tP and tG. U/O is already used for a specific purpose, D is used in UHD and interruption is ambiguous.

M