| b300575e | 22-Feb-2022 |
Josh Lehan <krellan@google.com> |
pid/zone: Adding unscaled to cache and logging
The "ReadReturn" structure, and the cache within DbusPidZone, have
been widened, to hold both the scaled and the original unscaled values
at the same t
pid/zone: Adding unscaled to cache and logging
The "ReadReturn" structure, and the cache within DbusPidZone, have
been widened, to hold both the scaled and the original unscaled values
at the same time. This allows logging to show both at once, and also
clears up confusion/bugs resulting from storing one or the other and
losing track of which was which.
Compatibility setValue() and getCachedValue() functions still
retained, so this will not break other sensors. These functions still
only take a single argument/return, which will be used for both value
and unscaled, indicating scaling is unknown or irrelevant to this
sensor.
Also, the PWM output of the PID loop appears in the log file,
conveniently right alongside the RPM input of the PID loop.
An output cache has been added to the zone interface, and, unlike the
input cache, use of it is optional. It is only to help populate the
logging, so subclasses are free to ignore it if they want.
Tested: In the logging files, I can see both PWM and RPM, and they are
consistent, showing how the PID loop is trying to update the PWM to
target the desired RPM.
Example: Here's /tmp/zone_0.log on my system
epoch_ms,setpt,fan0_tach,fan0_tach_raw,fan0_tach_pwm,fan0_tach_pwm_raw,bmcmargin_zone0,bmcmargin_zone0_raw,thermal_zone0,thermal_zone0_raw,failsafe
3097918,3818.42,0.748267,11224,0,0,0.724753,56.812,0.745098,62,0
3098022,3818.42,0.748267,11224,0.266666,67,0.724753,56.812,0.745098,62,0
3098132,3818.42,0.748267,11224,0.266666,67,0.724753,56.812,0.745098,62,0
Here's what we can now learn:
The desired setpoint is 3818 RPM.
The fan is at 74.8% of scale, which is 11224 RPM.
The written PWM, after the first PID loop pass, is a raw value of 67,
which is 26.6% of scale.
The first margin temperature is 56.8 degrees of margin, which is 72.4%
of scale.
The second margin temperature is 62 degrees of margin, which is 74.5%
of scale.
This zone is not in failsafe mode.
As you can see, this will be rather useful for PID loop tuning.
Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I972a4e4a3b787255f0dcafa10d4498ee58b682f0
show more ...
|
| ca791156 | 21-Sep-2020 |
Josh Lehan <krellan@google.com> |
FanController/ThermalController: Clean up PID input math
Adding checking against floating-point oddities,
such as NAN, +INF, or -INF, appearing as input,
which would mess up the PID loop math,
causi
FanController/ThermalController: Clean up PID input math
Adding checking against floating-point oddities,
such as NAN, +INF, or -INF, appearing as input,
which would mess up the PID loop math,
causing corrupt output.
If a fan or thermal input value is NAN, +INF, or -INF,
that value will be omitted from contributing to PID loop input.
If all values were omitted for that PID loop,
existing code already hardcodes a value of 0 for fan,
and I added similar code to also hardcode 0 for thermal.
It makes sense to use a placeholder value of 0 degrees of margin,
because this will make the fans spin fast,
if for some reason the zone is not already in failsafe mode by now.
Note that negative values are not allowed for fan,
but they are allowed for thermal.
Tested: Works for me, and PID loops no longer output garbage
when debugging a sensor malfunction while in tuning mode,
making tuning mode much more usable. If not in tuning mode,
the normal failsafe feature would have kicked in,
masking this garbage from appearing in the output anyway.
Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I7aee812ebaeff209f84cef0db28973696f782ef9
show more ...
|
| 55ccad65 | 21-Sep-2020 |
Josh Lehan <krellan@google.com> |
DbusPidZone: Allow per-zone setpoint files during tuning
In tuning mode, in addition to the overall setpoint file,
also check for the existence of per-zone setpoint files.
If they exist, and contai
DbusPidZone: Allow per-zone setpoint files during tuning
In tuning mode, in addition to the overall setpoint file,
also check for the existence of per-zone setpoint files.
If they exist, and contain a parseable RPM number,
they will be used. If both per-zone and overall files exist,
the per-zone will override the overall, appropriately for each zone.
Better error checking has been added,
detecting common user mistake of using PWM instead of RPM,
throttling error messages to avoid repetitive output.
Tested: It worked, here's an example...
echo 5000 > /etc/thermal.d/setpoint.zone0
echo 7000 > /etc/thermal.d/setpoint
echo 9000 > /etc/thermal.d/setpoint.zone2
Zone 0 will try for 5000 RPM, Zone 2 will try for 9000 RPM,
and Zone 1 (and all other zones) will try for 7000 RPM.
Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: Ic78d0fd2a0c32308356a0e2c7b03453416467c5b
show more ...
|