Add progress bars for experiment launch timing #38
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds off a bunch of previous work, but adds a handful of new features too. The big ideas are:
Experiment Setup Progress Bars
This adds progress bars for graph creation and experiment setup; these use combine progress bars and rich
Live
displays so that output are presented cleanly (e.g., graph creation progress, VM cache progress, and MC printouts do not clobber each other).Notably, this MR extends the
AbstractPlugin
to accept an (optional)console
keyword argument. This should have no impact on existing MC plugins that do not display output, but it allows MCs that do display output during setup to leverage this object and avoid competition with any live output coming directly from FIREWHEEL.Negative Time Progress Bar
The MR also adds a progress bar for experiment negative time to the output of
firewheel vm mix
. While defining progress through negative time is only particularly well-defined on a per VM basis, it seemed less than ideal to show n progress bars for each of the n VMs in the experiment. Instead, this uses the heuristic that overall progress through negative time is defined as the number of (negative time) schedule events that have been completed per the total number of negative time schedule events across all VMs.For practicality, "event" completion is defined for each VM as any negative time event that was scheduled before the VMs current time, which means that this heuristic is strictly conservative. Some subset of events in the queue that were all scheduled at the same time may actually have completed, but since the VM time has not advanced, they are not counted as "complete" by this metric.
Noting that schedules can be adapted as the experiment evolves, the total number of negative time events is not guaranteed to remain constant. Rich allows progress bars to update their total values, so this does not cause any trouble in implementation; however; it might surprise users who notice that their totals aren't fixed.
Finally, when the experiment is setting up or in positive time, the negative time progress bar is hidden to avoid visual clutter.