Skip to content
This repository has been archived by the owner on Jul 19, 2022. It is now read-only.

Do we need to bring back forecasting #235

Open
mormj opened this issue Apr 28, 2022 · 0 comments
Open

Do we need to bring back forecasting #235

mormj opened this issue Apr 28, 2022 · 0 comments

Comments

@mormj
Copy link
Contributor

mormj commented Apr 28, 2022

In GR3, forecast() was pretty closely tied to the backpressure based scheduler - give me the number of inputs you need based on producing this many outputs.

This is why in GR4, we got rid of it, and let the work() function handle forecasting on its own and returning INSUFFICIENT if it doesn't line up

But here is a case where forecasting could be useful:

  • Want to wrap the work function of a block generically so that it can run work on a PDU - the block is not designed for PDU specifically
  • Given an input size, we need to know how many outputs to produce and create that sized PDU as input to the work function
  • We can use relative_rate, then see what was produced, and adjust??

Bottom line is there is a tradeoff:

  • Want to make it easiest for the block developer
  • Want to not tie block impl into a specific scheduling paradigm

Thoughts?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant