-
Notifications
You must be signed in to change notification settings - Fork 63
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
Update the resource-utilization calc: average over the last N ms #127
Update the resource-utilization calc: average over the last N ms #127
Conversation
…lliseconds. Previously, RU was calculated since program-start. This commit changes this calculation to average over the last N milliseconds.
@@ -49,7 +49,9 @@ void ResourceUsageLogger::start(std::chrono::milliseconds period) | |||
std::cout << "[ResourceUsageLogger]: Logging to " << m_filename << std::endl; | |||
|
|||
m_t1_real_start = std::chrono::steady_clock::now(); | |||
m_t1_user = std::clock(); | |||
// Question: make this a flag? That is, calc RU since program start or over |
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 we have a situation in which we need to use the previous behavior, we could add a flag.
I don't foresee an use case for this though, and wrt some kind of "backward compatibility", we always looked into the last values of the CPU, right before the program finishes (which now we could get more quickly, after maybe just 5 seconds instead of 60).
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.
Sounds good, I'll remove the question/comment. Thanks.
I'm going to give it a try, but looks good! |
// resource utilization only over the last `period` milliseconds, *not* | ||
// since program start. | ||
m_t1_user = std::clock(); | ||
m_t1_real = std::chrono::steady_clock::now(); |
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.
Ok note here how both of these members are updated right before sleep_until
. Now the denominator, time_elapsed_real_ms
, should reflect the period
duration here.
Note that I don't think you can compare the actual value from top
to what you see in the resources.txt
file. As I understand it, top
expresses %CPU
as a percentage of total CPU time. However, here we are expressing our cpu%
as the approximate CPU time used by our process over monotonic wall-clock time. e.g.
// cpu time of our process / monotonic wall clock time, using these
std::clock() / std::chrono::steady_clock::now();
- https://en.cppreference.com/w/cpp/chrono/c/clock
- https://en.cppreference.com/w/cpp/chrono/steady_clock/now
I think top
and our calculation are somewhat different, but I could certainly be wrong.
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.
Yes you're right, top
and our calculation are a bit different. If you multiply the CPU% we get in our way, by the number of cores of your system, the values are quite similar.
I mostly refered to the top
approach of averaging every 1 or 2 seconds, so it doesn't reflect the past before that.
For that, the CPU load is what helps. I don't think we care about that so our approach is fine!
|
Overview
Previously, resource-utilization (RU) was calculated as an average since program-start. This PR changes the calculation to average over the last
period
milliseconds, whereperiod
is the sampling flag, e.g.---sampling 1000
.This change brings RU more inline with programs like
htop
and is the idea, and request, of @mauropasseirobot_benchmark
? E.g. exposing the ability to choose the desired behavior?Tests
Tests were conducted within a
rolling
docker containerwhite-mountain
topology on x86this branch:
the target master branch:
cpu[%]
falls off much more quicklyresources.txt
vs. simply the last line or two...