CPU load scale is off on MacOS #499
Comments
|
#455 would partially fix this because then the load would at least be coloured. |
dolmen
added
CPU load
|
The main issue is that loadavg is used with an incorrect expectation of a [0,1] range. See #391 where the bug was introduced. |
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Closes liquidprompt#499, liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Finally, it improves the documentation of the LP_LOAD_THRESHOLD value to make it clear that it represents a centiload value that will be multiplied with the number of CPUs in the system to calculate the actual load average threshold that will be compared with the system's representation of the load average. Closes liquidprompt#499, liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Finally, it improves the documentation of the LP_LOAD_THRESHOLD value to make it clear that it represents a centiload value that will be multiplied with the number of CPUs in the system to calculate the actual load average threshold that will be compared with the system's representation of the load average. Closes liquidprompt#499, liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Finally, it improves the documentation of the LP_LOAD_THRESHOLD value to make it clear that it represents a centiload value that will be multiplied with the number of CPUs in the system to calculate the actual load average threshold that will be compared with the system's representation of the load average. Closes liquidprompt#499, liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Finally, it improves the documentation of the LP_LOAD_THRESHOLD value to make it clear that it represents a centiload value that will be multiplied with the number of CPUs in the system to calculate the actual load average threshold that will be compared with the system's representation of the load average. Closes liquidprompt#499, closes liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 7, 2020
Liquidprompt's load feature currently assumes, incorrectly, that the load average is a percentage (it isn't) that can be converted directly to CPU utilisation (it can't). Because the load average is a gauge reading with an essentially unlimited ceiling, ensure the colouring function is passed an appropriate ceiling instead of the default value of 100. This ceiling is now set (rather arbitrarily) at 20*$LP_LOAD_THRESHOLD, meaning the "highest" colour starts being used at 18*$LP_LOAD_THRESHOLD. To handle the case where the actual load exceeds the 20*$LP_LOAD_THRESHOLD ceiling, the _lp_color_map() function is changed to apply the "highest" colour (instead of no colour) whenever the supplied value exceeds the ceiling of the scale. This change is an alternative implementation of what has already been proposed in liquidprompt#455. Finally, it improves the documentation of the LP_LOAD_THRESHOLD value to make it clear that it represents a centiload value that will be multiplied with the number of CPUs in the system to calculate the actual load average threshold that will be compared with the system's representation of the load average. Closes liquidprompt#499, closes liquidprompt#530. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jun 11, 2020
In some cases, scales have no upper ceiling. In that case the supplied value might exceed the (arbitrary) ceiling used by `_lp_color_map()`. Ensure that the "reddest" possible colour is output in such cases. Closes liquidprompt#455, closes liquidprompt#499. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jul 3, 2020
In some cases, scales have no upper ceiling. In that case the supplied value might exceed the (arbitrary) ceiling used by `_lp_color_map()`. Ensure that the "reddest" possible colour is output in such cases. Closes liquidprompt#455, closes liquidprompt#499. Signed-off-by: Tore Anderson <[email protected]>
toreanderson
added a commit
to toreanderson/liquidprompt
that referenced
this issue
Jul 3, 2020
In some cases, scales have no upper ceiling. In that case the supplied value might exceed the (arbitrary) ceiling used by `_lp_color_map()`. Ensure that the "reddest" possible colour is output in such cases. Closes liquidprompt#455, closes liquidprompt#499. Signed-off-by: Tore Anderson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Shell: zsh
Operating system: macOS
Liquid Prompt version (tag, commit): 1.11
Often the CPU load percentage reported by liquidprompt is well over 100%. This means it won't be coloured by the gradient scale.
I've investigated a bit and found that liquidprompt uses
sysctl -n vm.loadavgto find the current CPU usage, then it divides it by the number returned fromsysctl -n ncpu(in my case this is 4) and multiplies by 100.The values from
sysctl -n vm.loadavgcan be well over 400%, though. I've seen it as high as10.88. So, it looks like liquidprompt is using the wrong value as the upper bound (though I couldn't tell you what that should be).The text was updated successfully, but these errors were encountered: