[Buildbot] #540: overhaul ETA calculation
Buildbot trac
trac at buildbot.net
Sat Oct 18 16:21:42 UTC 2014
#540: overhaul ETA calculation
------------------------+-----------------------
Reporter: ipv6guru | Owner: warner
Type: enhancement | Status: assigned
Priority: major | Milestone: 0.9.0
Version: 0.7.10 | Resolution:
Keywords: eta |
------------------------+-----------------------
Changes (by dustin):
* milestone: 0.9.+ => 0.9.0
Old description:
> The Progress and Expectation classes are overdue for a
> rewrite. They need to move to a scheme that I'll call
> Reverse Temporal Mapping because it sounds clever.
>
> The idea is that each StepProgress metric (an axis
> along which progress can be measured, like bytes of
> output or test cases run) should be sampled
> periodically during the Step. Nominally we'd like about
> 100 samples total, but if we have no idea how long the
> step will run then we can just sample every 10 seconds
> or something.
>
> Those samples form a graph of progress-versus-time. We
> then invert the graph to give us one of
> time-versus-progress. This is used to create an
> interpolation table that will map from progress values
> into elapsed seconds. During the next build, we'll take
> the current progress value and use this table to
> estimate how many seconds are left to go.
>
> The tables should be averaged over multiple builds, to
> provide some smoothing. The ETA values from the various
> metrics should be combined with some sort of weighted
> average (some metrics may be more accurate than others).
>
> We also need to handle overdue builds better. It may be
> useful to report both the ETA and the percentage
> complete (since a slow build that still produces the
> same output as before will show <%100 complete even
> when the build is overdue).
>
> It would also be useful to add some intstrumentation
> that lets us check the accurary of the ETA code,
> perhaps a table to show how the ETA changes as the
> build runs, comparing it to the actual elapsed time.
> The ETA should get more accurate as the build nears
> completion: it would be nice to see a graph of this
> convergence.
> Submitted:
> Brian Warner ( warner ) - 2005-05-18 05:19
New description:
The Progress and Expectation classes are overdue for a
rewrite. They need to move to a scheme that I'll call
Reverse Temporal Mapping because it sounds clever.
The idea is that each StepProgress metric (an axis
along which progress can be measured, like bytes of
output or test cases run) should be sampled
periodically during the Step. Nominally we'd like about
100 samples total, but if we have no idea how long the
step will run then we can just sample every 10 seconds
or something.
Those samples form a graph of progress-versus-time. We
then invert the graph to give us one of
time-versus-progress. This is used to create an
interpolation table that will map from progress values
into elapsed seconds. During the next build, we'll take
the current progress value and use this table to
estimate how many seconds are left to go.
The tables should be averaged over multiple builds, to
provide some smoothing. The ETA values from the various
metrics should be combined with some sort of weighted
average (some metrics may be more accurate than others).
We also need to handle overdue builds better. It may be
useful to report both the ETA and the percentage
complete (since a slow build that still produces the
same output as before will show <%100 complete even
when the build is overdue).
It would also be useful to add some intstrumentation
that lets us check the accurary of the ETA code,
perhaps a table to show how the ETA changes as the
build runs, comparing it to the actual elapsed time.
The ETA should get more accurate as the build nears
completion: it would be nice to see a graph of this
convergence.
Submitted:
Brian Warner ( warner ) - 2005-05-18 05:19
--
Comment:
I'm removing the existing support for this in #2818.
--
Ticket URL: <http://trac.buildbot.net/ticket/540#comment:7>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation
More information about the bugs
mailing list