You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 19, 2022. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
Bottom line is there is a tradeoff:
Thoughts?
The text was updated successfully, but these errors were encountered: