New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkg: make speed estimation more accurate #4963
Conversation
Signed-off-by: Ryan Leung <rleungx@gmail.com>
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
pkg/progress/progress.go
Outdated
p.lastTimeRemaining = remaining | ||
|
||
// We use window size / update interval to get the history length. | ||
historyLen := int(speedStatisticalWindow / updateInterval) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we set historyLen
as a constant(an attribute for Manager
) once Manager
created?
pkg/progress/progress.go
Outdated
// We use window size / update interval to get the history length. | ||
historyLen := int(speedStatisticalWindow / updateInterval) | ||
if len(p.history) > historyLen { | ||
p.history = p.history[1:] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this cause a GC problem? It seems once meet the historyLen, this operator will be done as frequently as the UpdateProgress
called? How about use a slice with constant length to implement the FIFOQueue? For example, we assume the historyLength
keep 5, and there is a slice::
1,2,3,4,5 (first=0,last:4)
when 6 comes, the slice changed to
6,2,3,4,5 (first=1,last=0)
and 7 comes:
6,7,3,4,5 (first=2,last=1)
Signed-off-by: Ryan Leung <rleungx@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #4963 +/- ##
==========================================
- Coverage 75.45% 75.25% -0.20%
==========================================
Files 298 298
Lines 29532 29542 +10
==========================================
- Hits 22282 22231 -51
- Misses 5318 5362 +44
- Partials 1932 1949 +17
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
pkg/progress/progress.go
Outdated
if p.lastTimeRemaining < remaining { | ||
p.lastTimeRemaining = remaining | ||
|
||
if p.history.Len() > p.historyLen { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if p.history.Len() > p.historyLen { | |
if p.history.Len() >= p.historyLen { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is on purpose because we will put one record when initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the actually length limit of p.history is historyLen+1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the actually length limit of p.history is
historyLen+1
?
IMO, historyLen
is used for time window. For example, if updateInterval is equal to one minute, then historyLen is equal to 10, so it takes 11 points
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change it to windowLengthLimit
Signed-off-by: Ryan Leung <rleungx@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/merge |
@nolouch: It seems you want to merge this PR, I will help you trigger all the tests: /run-all-tests Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
This pull request has been accepted and is ready to merge. Commit hash: c6bb46f
|
/merge |
@nolouch: It seems you want to merge this PR, I will help you trigger all the tests: /run-all-tests Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
Signed-off-by: Ryan Leung rleungx@gmail.com
What problem does this PR solve?
Issue Number: Ref #4640.
What is changed and how does it work?
This PR changes the way of calculating progress speed. After this PR, we use a sliding window to get the speed through the delta in a fixed time interval.
Now, the monitor becomes:
Check List
Tests
Release note