TagsTaskForce

From GNU Radio
Revision as of 01:36, 8 March 2017 by Mbr0wn (talk | contribs) (Imported from Redmine)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

TagsTaskForce[edit]

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[edit]

  • 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[edit]

  • 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[edit]

  • 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[edit]

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