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 -> wouldn't work
  • How would we know we're in the last fragment or not? -> 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 => 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 -> 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:
> A couple of ideas for the characters to print out if tagged streams are
> cut short or there is a gap between them:
>
> Tag interruption/preemption/overrun: “tI” or “tP” or “tO”
>
> Tag discontinuity/gap/underrun: “tD” or “tG” or “tU”
>
> Thoughts? “tO” and “tU” are more consistent with UHD, audio sink/source,
> and gr-osmosdr sink/source conventions, but I’m not sure they are
> accurate. Also since this will be coming from usrp_sink, I don’t want
> the characters to be confused with the UHD messages. I like “tP” and
> “tD” or “tP” and “tG”. “tI” could be hard to read since the letter “I”
> 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