FASSWG

From GNU Radio
Jump to navigation Jump to search

Functional Architectures for Signal Processing Systems Working Group

This page summarizes the activities of the Functional Architectures for Signal Processing Systems (FASS) Working Group

Workgroup Charter

The Functional Architectures for Signal Processing WG is dedicated to documenting and improving the functionality of GNU Radio's signal processing system design patterns. In addition to GNU Radio's highly mature continuous stream processing architecture, this group seeks to address a number of issues encountered in building stateful real-world systems which deal with discrete chunks of bursts of information and must be able to rapidly and precisely translate between each design pattern within a single application where appropriate for optimal code simplicity and efficiency.

Stated Goals

  • Quantify performance trade offs between various architectures
  • Clearly explain use cases for each architectural model
  • Provide clear examples for each model
  • Identify and implement architectural improvements to reconcile performance of each model
  • Improve interoperability and translation tools between architectural models

Group Meeting Schedule

  • Monthly G+ Hangout TBD?

GNU Radio Conference 2014 Topics

http://www.trondeau.com/gnu-radio-conference-2014/

The first official meeting of the FASP working group will occur at the GNU Radio Conference 2014 in Washington, DC, below is a partial list of technical topics to be used as guide-marks for discussion at the discussion

The primary objectives of the WG at this conference will be to obtain consensus and input on the currently used architectures and concerns within GNU Radio, formalize the language with which we discuss these practices within the community, identify interested parties interested in participating within the workgroup and coordinating efforts to achieve the stated goals above, and documenting various ongoing efforts by different parties to improve functional architectural capabilities.

  • Model1: Traditional Streaming Architecture
    • Highly Mature
    • Tags carrying information, not signaling/headers
    • Lingering Latency Concerns
      • Methods for improving latency
  • Model2: Tagged Stream Item Architecture
    • Large Stream Item Buffer Issues
    • Tagged Item Fragmentation
    • Forecast Requirements / Variable Rate Blocks
    • Potential TPB Scheduler Improvements
    • Tagged Stream Item demarcation method (length up front, start + trailer, etc)
  • Model3: Pure Message Passing Architecture
    • PMT Efficiency Concerns / Memory Efficiency
    • Potential for Handler Concurrency
    • Well defined message formats
  • Model Translation (Mixing models in an application)
    • Message to/from Tagged Streams (existing blocks)
    • Message to/from Traditional Stream (existing blocks, eventstream)
    • Tagged Stream Item/Message Handler Inter-operable Base Class
    • Characterizing Model Trade-offs and performance
      • Development Time
      • Throughput
      • Latency