fdoray@chromium.org pmonette@chromium.org catan-team@chromium.org See definition of PerformanceClass.AverageCPU10.ProcessName. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). anthonyvd@chromium.org fdoray@chromium.org pmonette@chromium.org catan-team@chromium.org Sum of the average CPU utilization of each utility process of the subtype {Subtype}, read out at each two-minute interval. The utilization is in the 0-100% range per CPU, which is then summed up and multiplied by 100. I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. Capped at 160,000 (equivalent to 16 cores fully loaded) to accomodate the long tail of heavy workloads. If no process of type {Subtype} existed during the interval, a sample of zero is still emitted. Not recorded on Android. On Windows, this is not recorded on CPUs that do not support constant rate TSC. fdoray@chromium.org pmonette@chromium.org catan-team@chromium.org Sum of the average CPU utilization of each process of the type {ProcessName}, read out at each two-minute interval. The utilization is in the 0-100% range per CPU, which is then summed up and multiplied by 100. I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. Capped at 160,000 (equivalent to 16 cores fully loaded) to accomodate the long tail of heavy workloads. If no process of type {ProcessName} existed during the interval, a sample of zero is still emitted. Not recorded on Android. On Windows, this is not recorded on CPUs that do not support constant rate TSC. pmonette@chromium.org catan-team@chromium.org Records whether or not the CPU supports constant rate TSC, which allows a more precise calculation of the CPU usage of a process. Recorded during startup when the ProcessMonitor is instantiated. Only Recorded on Windows. olivierli@chromium.org catan-team@chromium.org See definition of PerformanceMonitor.IdleWakeups2.ProcessName. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). olivierli@chromium.org catan-team@chromium.org The sum of the average CPU idle wakeups per second of each process of the type {ProcessName}, sampled every two minutes. NOTE: This metric has one signigicant limitation, it doesn't report the CPU usage of processes that terminate before the end of the interval. This means that short lived processes will rarely be included in the data. Furthermore, we know that short-lived processes are very common (see Renderer.ProcessLifetime). A future version of this metric will address this limitation. olivierli@chromium.org catan-team@chromium.orgg See definition of PerformanceMonitor.PackageExitIdleWakeups2.ProcessName. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). olivierli@chromium.org catan-team@chromium.orgg (Mac only) The sum of the average package exit idle wakeups per second of each process of the type {ProcessName}, sampled every two minutes. This is a subset of wakeups that indicate that the processor complex was taken out of low-power state. For more info, see the powermetrics man page on macOS. NOTE: This metric has one signigicant limitation, it doesn't report the CPU usage of processes that terminate before the end of the interval. This means that short lived processes will rarely be included in the data. Furthermore, we know that short-lived processes are very common (see Renderer.ProcessLifetime). A future version of this metric will address this limitation. olivierli@chromium.org catan-team@chromium.org Record the usage scenario that applies to the last 2 mins of Chrome use. Recorded every two minutes on a timer. For more information on user scenarios see go/chrome_power_use_per_scenario. Values in the enum match the variants present in the "UsageScenario" variants. dbasehore@chromium.org chromeos-platform-power@google.com The battery percentage of the system when the AC charger is unplugged. This metric is recorded upon unplug of an AC charger, unless the system is shutdown. Since this metric is only reported when the battery percentage has reached the hold percent (the battery charge % that charging is delayed at, which is 80%) for Adaptive Charging, most values should be high. We record this under several variants, which split this result by the type of charging that is used to charge to full once the hold percent is reached. Normal charging uses the default rate of charging, slow charging uses a battery charge current limit of 0.1C (10% of battery design capacity) and mixed charging is a combination of both normal and slow charging which can occur when the unplug time prediction moves sooner, resulting in the switch from slow charging to normal charging in order to finish charging by the unplug time predicted. {AdaptiveChargingType} dbasehore@chromium.org chromeos-platform-power@google.com The difference between the correct delay time and the actual delay time for Adaptive Charging, as computed by (correct delay - actual delay) in minutes. Adaptive Charging delays charging from a hold charge percentage, 80%, to full if it predicts the charger will be unplugged more than 3 hours in the future. The correct delay time ends exactly 3 hours before the user unplugs the charger, or 2 hours before the user unplugs if the available time is less than 3 hours. This metric is recorded upon unplug of an AC charger, if the hold percent was reached. We record this under several variants, which split this result by whether Adaptive Charging is enabled and active, a heuristic disabled the feature, the user canceled the feature for this use, the user disabled the feature, or the feature is not supported on the hardware class. We still record the metric if the feature is not supported, since we may backport support to older systems, and we'd like to know how well the ML model does before enabling support. Since metrics don't work with negative values, this is additionally split across Late and Early variants. The absolute values of negatives are reported under the Late variant. Positive and 0 values are reported under the Early variant. dbasehore@chromium.org chromeos-platform-power@google.com Total time, in minutes, for Adaptive Charging. This metric is recorded upon unplug unplug of an AC charger, if the hold percent (the battery charge % that charging is delayed at, which is 80%) for Adaptive Charging was reached. This is split by two variants, Available and Delay, which report the available time for Adaptive Charging and the delay time for Adaptive Charging. dbasehore@chromium.org chromeos-platform-power@google.com The difference, in minutes, between when the AC charger is unplugged and when it was predicted to be unplugged by the Adaptive Charging feature. Computed as (actual - predicted). This metric is recorded upon unplug of an AC charger, if the hold percent (the battery charge % that charging is delayed at, which is 80%) for Adaptive Charging was reached. We record this under several variants, which split this result by whether Adaptive Charging is enabled and active, a heuristic disabled the feature, the user canceled the feature for this use, the user disabled the feature, or the feature is not supported on the hardware class. We still record the metric if the feature is not supported, since we may backport support to older systems, and we'd like to know how well the ML model does before enabling support. Since metrics don't work with negative values, this is additionally split across Late and Early variants. The absolute values of negatives are reported under the Late variant. Positive and 0 values are reported under the Early variant. dbasehore@chromium.org chromeos-platform-power@google.com This shows the time spent fully charged while on AC in minutes. We record this under several variants, which split this result by whether Adaptive Charging is enabled and active, a heuristic disabled the feature, the user canceled the feature for this use, the user disabled the feature, or the feature is not supported on the hardware class. We still record the metric if the feature is not supported, since we may backport support to older systems, and we'd like to know how well the ML model does before enabling support. dbasehore@chromium.org chromeos-platform-power@google.com The time it takes to fully charge from the Adaptive Charging hold percent (the battery charge % that we delay charging at). This is recorded to make sure that we leave enough time for systems to fully charge to full from the hold percent. We record this under several variants, which split this result by the type of charging that is used to charge to full once the hold percent is reached. Normal charging uses the default rate of charging, slow charging uses a battery charge current limit of 0.1C (10% of battery design capacity) and mixed charging is a combination of both normal and slow charging which can occur when the unplug time prediction moves sooner, resulting in the switch from slow charging to normal charging in order to finish charging by the unplug time predicted. {AdaptiveChargingType} bkersten@chromium.org slangley@chromium.org The Ambient Light Sensor reading sampled on resume from suspend. Only applicable to Chrome OS. eseckler@chromium.org khokhlov@chromium.org woa-performance@google.com Records the average CPU load caused by the corresponding process over the last 30 (or more) seconds. Emitted at the end of each such period, so not more often that once in 30 sec. Note that CPU load can be greater than 100% on milti-core systems. puthik@chromium.org mqg@chromium.org chromeos-platform-power@google.com The level of the backlight as a percentage {PrivacyScreenState} when the device is {PowerSource}. Sampled every 30 seconds. Chrome OS only. puthik@chromium.org chromeos-platform-power@google.com Chrome OS {BatteryCapacityType} battery capacity in milliwatt-hours. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery charge health percentage. Sampled once when device starts charging. pmonette@chromium.org fdoray@chromium.org The availability of the battery discharge granularity. If true, Power.BatteryDischargeGranularity is reported for this client. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. Reported only on Windows, when a single battery is installed and the operating system says that the unit is mWh. pmonette@chromium.org fdoray@chromium.org Reports if the battery discharge granularities are ordered according to the MSDN documentation. The documentation states that the most coarse granularity is the first element among all reporting scales. Reported only on Windows, every time the battery state is queried. pmonette@chromium.org fdoray@chromium.org The granularity of the battery discharge rate value as reported by the operating system, if available. Always the most coarse granularity among all the reporting scales of the battery, regardless of the current capacity. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. Reported only on Windows, when a single battery is installed and the operating system says that the unit is mWh. pmonette@chromium.org fdoray@chromium.org The granularity of the battery discharge rate value as reported by the operating system, if available. Always the most coarse granularity among all the reporting scales of the battery, regardless of the current capacity. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. Reported only on Windows, when a single battery is installed and the operating system says that the unit is mWh. pmonette@chromium.org fdoray@chromium.org Battery discharge mode describing whether Power.BatteryDischargeRateMilliwatts6.TenMinutes could be reported, and why. Windows only. This is reported when a 1 minute periodic timer fires and at least 10 minutes have elapsed since the last report or startup. etiennep@chromium.org olivierli@chromium.org Battery discharge mode describing whether Power.BatteryDischargeRateMilliwatts6 could be reported, and why. On Windows and ChromeOS, this is reported when a 1 minute periodic timer fires. On macOS, this is reported when an IOPMPowerSource state change notification fires (typically every minute but may happen more frequently). This is recorded for {UsageScenario}. This contains {IntervalType}. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery discharge rate in mW sampled every 30 seconds while the device runs on battery. pmonette@chromium.org fdoray@chromium.org Battery discharge in milliwatts over a 10 minutes interval. Windows only. Example: Used capacity at the beginning of the interval: 1000 mWh, used capacity at the end of the interval: 1010 mWh, Discharge: (1010-1000) = 10 mWh per 10 minutes, reported value: 60 mW. Reported when "discharging" is reported to Power.BatteryDischargeMode5.TenMinutes. etiennep@chromium.org olivierli@chromium.org lgrey@chromium.org Battery discharge in milliwatts over a 1 minute interval. Example: Used capacity at the beginning of the interval: 1000 mWh, used capacity at the end of the interval: 1010 mWh, Discharge: (1010-1000) = 10 mWh per 1 minute, reported value: 600 mW. Reported when "discharging" is reported to Power.BatteryDischargeMode5. This is recorded for {UsageScenario}. This contains {IntervalType}. This is recorded for {BatterySaverMode}. pmonette@chromium.org catan-team@chromium.org Battery discharge in milliwatts, example: - Used capacity at the beginning of the interval: 1000 mWh; - Used capacity at the end of the interval: 1010 mWh; - Discharge: (1010-1000) = 10 mWh per minute - Reported value: 600 mW. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. Clients with a coarse battery discharge granularity (>17 mWh) are excluded. This is recorded for {UsageScenario}. This contains {IntervalType}. This is recorded for {BatterySaverMode}. etiennep@chromium.org olivierli@chromium.org lgrey@chromium.org Battery discharge rate per minute, with 1/10000 of full charge resolution, example: - Battery capacity = 4000 mAh; - Battery charge at the beginning of the interval: 3900 mAh; - Battery charge at the end of the interval: 3700 mAh; - Discharge proportion: (3900-3700) / 4000 = 0.05 - Reported value: 500. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. This is recorded for {UsageScenario}. This contains {IntervalType}. This is recorded for {BatterySaverMode}. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery discharge rate in mW while the system was suspended, sampled at resume. Only reported if the system was on battery power both before suspending and after resuming, if the energy level didn't increase while suspended (which would indicate that an AC adapter was connected), and if the system was suspended for at least a minute. puthik@chromium.org chromeos-platform-power@google.com ChromeOS rolling average of the battery life while in active state, measured in minutes using the {BatteryCapacityType}. This is calculated by taking the average of the last 10 samples of the Power.BatteryLife.{BatteryCapacityType} metrics. The detail version put the data outside of 5-13 hours in to the underflow and overflow bucket to have more data resolution at the median range. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery life while in active state, measured in minutes using the {BatteryCapacityType}. This is calculated using size of the battery divided by the battery discharge rate sampling, i.e., Power.BatteryDischargeRate. Note that the size of the battery is derated by the low battery shutdown percent. The detail version put the data outside of 5-13 hours in to the underflow and overflow bucket to have more data resolution at the median range. puthik@chromium.org chromeos-platform-power@google.com ChromeOS rolling average of the battery life while in active state, measured in minutes using the {BatteryCapacityType}. This is calculated by taking the average of the last 10 samples of the Power.BatteryLife.{BatteryCapacityType} metrics. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery life while in active state, measured in minutes using the {BatteryCapacityType}. This is calculated using size of the battery divided by the battery discharge rate sampling, i.e., Power.BatteryDischargeRate. Note that the size of the battery is derated by the low battery shutdown percent. puthik@chromium.org chromeos-platform-power@google.com Chrome OS battery life while suspended, measured in hours using the {BatteryCapacityType}. This is calculated using size of the battery divided by the battery discharge rate sampling, i.e., Power.BatteryDischargeRateWhileSuspended. ryansturm@chromium.org tbansal@chromium.org The drop in battery since the last operating system battery update as a percent of total device battery. If the drop is not a round percentage point, the unreported amount will be carried over until the battery level drops by a full percentage point. Recorded when the battery level drops by more than a percentage point. If the user charges the device, the battery tracking is reset (the amount carried over is reset). This histograms sum is most likely the most useful figure when comparing experiments. Recorded even when Chrome is in the background. puthik@chromium.org chromeos-platform-power@google.com Chrome OS remaining battery charge as percent of the maximum battery charge, sampled when charging starts. Warning: this histogram was expired from 2022-05-01 to 2024-04-12; data may be missing. zactu@google.com chromeos-bsm@google.com ChromeOS time from Battery Saver activation that it took the user to increase the backlight brightness above what Battery Saver set. bleung@chromium.org puthik@chromium.org chromeos-platform-power@google.com Connected charging ports on Chrome OS. A sample is reported every time that the power manager polls sysfs (typically every 30 seconds). Ordinals are assigned based on the lexicographical ordering of power supply names from sysfs and have no implied correspondence with ports' physical locations. For example, with ports 'CROS_USB_PD_CHARGER0' and 'CROS_USB_PD_CHARGER1', 'first' refers to the former and 'second' to the latter. To determine a port's physical location, see the powerd charging_ports pref in the device's overlay. Warning: this histogram was expired from 2022-04-25 to 2024-04-12; data may be missing. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome, split by process type. Currently only implemented on Android. For every second of CPU time consumed by one process, a sample is recorded into the bucket for the process's type. Samples are recorded periodically depending on the task load of each process's main thread. The histogram thus shows the total sum of CPU time seconds spent per process type across all users. For a histogram of daily per-user values, select "Per-Client Aggregation Mode". eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome/WebView in the {Visibility} state, split by process type. Currently only implemented on Android. For every second of CPU time consumed by one process, a sample is recorded into the bucket for the process's type. Samples are recorded periodically depending on the task load of each process's main thread. The histogram thus shows the total sum of CPU time seconds spent per process type across all users. For a histogram of daily per-user values, select "Per-Client Aggregation Mode". eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome's {ProcessType} process, split by thread type. Currently only implemented on Android. For every second of CPU time consumed by one thread, a sample is recorded into the bucket for the thread's type. CPU time consumed by a process that cannot be attributed to a specific thread is recorded into the "UnattributedThread" bucket. Samples are recorded periodically depending on the task load of each process's main thread. The histogram thus shows the total sum of CPU time seconds spent per thread type (within {ProcessType} processes) across all users. For a histogram of daily per-user values, select "Per-Client Aggregation Mode". eseckler@chromium.org mthiesse@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome's {ProcessType} process, split by thread type and process visibility. Currently only implemented on Android. For every second of CPU time consumed by one thread, a sample is recorded into the bucket for the thread's type. CPU time consumed by a process that cannot be attributed to a specific thread is recorded into the "UnattributedThread" bucket. Samples are recorded periodically depending on the task load of each process's main thread. The histogram thus shows the total sum of CPU time seconds spent per thread type (within {ProcessType} processes) across all users when the process {Visibility}. For a histogram of daily per-user values, select "Per-Client Aggregation Mode". mka@chromium.org chromeos-platform-power@google.com The amount of time a system spent awake every time it woke up in dark resume. Warning: this histogram was expired from M85 to 2024-04-12; data may be missing. mka@chromium.org chromeos-platform-power@google.com The amount of time a system spent awake every time it woke up in dark resume triggered by an unknown or unsupported wake trigger. Warning: this histogram was expired from 2020-08-03 to 2024-04-12; data may be missing. mka@chromium.org chromeos-platform-power@google.com The amount of time a system spent awake every time it woke up in dark resume triggered by a WiFi disconnect. Warning: this histogram was expired from M85 to 2024-04-12; data may be missing. mka@chromium.org chromeos-platform-power@google.com The amount of time a system spent awake every time it woke up in dark resume triggered by a WiFi packet pattern match. Warning: this histogram was expired from M85 to 2024-04-12; data may be missing. mka@chromium.org chromeos-platform-power@google.com The amount of time a system spent awake every time it woke up in dark resume triggered by a net detect SSID match. Warning: this histogram was expired from M85 to 2024-04-12; data may be missing. mka@chromium.org chromeos-platform-power@google.com The number of times a system woke up in dark resume in an hour. Note that this value is scaled up or down to an hour based on the amount of time the system spent in suspend. So if the system suspended for 20 minutes and woke up 3 times, it would report a value of 9. Warning: this histogram was expired from 2020-08-02 to 2024-04-12; data may be missing. mqg@chromium.org amoylan@chromium.org chromeos-power-team@google.com The dimming events inside power_manager.metrics.DimEvent, recorded when a quick-dim/standard-dim starts or ends. The device is on {PowerSource} when the metrics is recorded. mhiramat@google.com cros-suspend-resume@google.com The time that the user process took to display UI on the Chrome OS device from suspend-to-RAM and suspend-to-Disk state, which starts when user processes are woken up by the kernel, and stops when SetIsProjecting signal is caught by power_manager. This is recorded when resuming from suspend. The device is on {PowerSource} when the metrics is recorded. eseckler@chromium.org khokhlov@chromium.org woa-performance@google.com chrome-analysis-team@google.com Periodically samples the battery capacity drained while Chrome is a foreground app and the device is on battery power {DarkeningType}. Sampled every 30 seconds while foregrounded. Also sampled when Chrome is backgrounded or the device connects to a charger. {Exclusive} Sample values are reported in microampere-hours and averaged over successive sampling points without a change in capacity counter values. Since the capacity counter resolution differs between device models, averaging the values allows us to make comparisons between frequent small capacity drops and infrequent large drops. For example, a 20,000 uAh drop over two successive periods of 30 seconds will be reported as two samples of 10,000 uAh. For more details, see http://bit.ly/chrome-android-foreground-battery-drain. Only supported on Android. For WebView, the metric considers the time during in which at least one WebView is visible on the screen as "foreground" time. For Chrome, it considers any time the Chrome app is visible, including when in multi-window mode. Note that the capacity counter can be implemented in different ways by different devices/OEMs and its accuracy can vary (across devices and at different times on the same device, also due to environmental factors like device temperature or charge level). We've found looking at the 99%ile-trimmed mean more useful than looking at specific percentiles, especially when filtering for specific device models. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Periodically samples the battery capacity drained while Chrome is a foreground app and the device is on battery power. Sampled every 30 seconds while foregrounded. Also sampled when Chrome is backgrounded or the device connects to a charger. {Exclusive} Sample values are reported as provided by the battery capacity counter (in microampere-hours). Because the resolution of this counter is rather coarse (usually between 500 and 50,000 uAh), the uAh value may have been drained over a longer time period than 30 seconds. See also Power.ForegroundBatteryDrain.30SecondsAvg, which averages the values over successive sampling points without change in counter values. Only supported on Android. For WebView, the metric considers the time during in which at least one WebView is visible on the screen as "foreground" time. For Chrome, it considers any time the Chrome app is visible, including when in multi-window mode. Note that the capacity counter can be implemented in different ways by different devices/OEMs and its accuracy can vary (across devices and at different times on the same device, also due to environmental factors like device temperature or charge level). kraskevich@google.com woa-performance@google.com Similar to Power.ForegroundBatteryDrain.30Seconds, with additional Chrome usage scenario classification: {LoadingScenario} and {InputScenario}. {Exclusive} eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Records a sample for every 0.1 milliampere-hours of battery capacity that are drained while Chrome is a foreground app and the device is on battery power. The battery counter is inspected every 30 seconds while foregrounded. It is also inspected when Chrome is backgrounded or the device connects to a charger. The histogram thus shows the total sum of battery capacity consumed across all users. {Exclusive} Only supported on Android. For WebView, the metric considers the time during in which at least one WebView is visible on the screen as "foreground" time. For Chrome, it considers any time the Chrome app is visible, including when in multi-window mode. Note that the capacity counter can be implemented in different ways by different devices/OEMs and its accuracy can vary (across devices and at different times on the same device, also due to environmental factors like device temperature or charge level). For a histogram of daily per-user values, see the computed histogram Power.DailyForegroundBatteryDrain. kraskevich@google.com woa-performance@google.com Similar to Power.ForegroundBatteryDrain.30Seconds, with additional Chrome usage scenario classification: {LoadingScenario} and {InputScenario}, and device's subsystem classification: {Subsystem} {Exclusive} This metric uses a more accurate (but less widely supported) underlying API https://developer.android.com/reference/android/os/health/SystemHealthManager. The reported value is energy consumed during the 30s interval in microwatt-hours. pmonette@chromium.org catan-team@chromium.org Records whether or not the reporting client has a battery discharge granularity less or equal to 17 mWh, which is the threshold to report the Power.BatteryDischargeRatePreciseMilliwatts histogram. This is reported at the end of every valid 1 minute interval. An invalid interval is one that deviate too much from 1 minute, which can be caused by the computer going to sleep, or the OS sending multiple notifications in a row. Only Recorded on Windows. eshimanovich@google.com chromeos-platform-power@google.com ChromeOS highest current fan speed, reported every 30 seconds from the EC. This is logged only on a periodic tick; no other events trigger this report. This is only reported from Chromebooks with fans that interface with the CrOS EC. Multiply value by 100 to get the fan speed in rpm. pmonette@chromium.org catan-team@chromium.org Records the time between each IOPMPowerSource event. The recorded value is clamped between 55 seconds and 65 seconds for maximum precision around the expected value. Only recorded on MacOS. pmonette@chromium.org catan-team@chromium.org Records the time between each IOPMPowerSource event. The recorded value is not clamped and covers the range from zero seconds to 3 minutes. Only recorded on MacOS. puthik@chromium.org mhiramat@google.com chromeos-platform-power@google.com cros-suspend-resume@google.com The time that the kernel took to resume the Chrome OS device from suspend-to-RAM state when running on AC at pre-suspend time. puthik@chromium.org mhiramat@google.com chromeos-platform-power@google.com cros-suspend-resume@google.com The time that the kernel took to resume the Chrome OS device from suspend-to-RAM state when running on battery at pre-suspend time. Warning: this histogram was expired from 2024-05-26 to 2024-07-15; data may be missing. puthik@chromium.org mhiramat@google.com chromeos-platform-power@google.com cros-suspend-resume@google.com The time that the kernel took to suspend-to-RAM the Chrome OS device when running on AC. Warning: this histogram was expired from 2020-01-26 to 2024-07-15; data may be missing. puthik@chromium.org mhiramat@google.com chromeos-platform-power@google.com cros-suspend-resume@google.com The time that the kernel took to suspend-to-RAM the Chrome OS device when running on battery. Warning: this histogram was expired from 2022-04-10 to 2024-07-15; data may be missing. tbroch@chromium.org The level of the keyboard backlight as a percentage. Sampled every 30 seconds. mqg@chromium.org amoylan@chromium.org chromeos-power-team@google.com The lock events inside power_manager.metrics.LockEvent, recorded when a quick-lock/standard-lock starts. The device is on {PowerSource} when the metrics is recorded. lgrey@chromium.org olivierli@chromium.org Thermal state of the user's machine as reported by macOS's [NSProcessInfo thermalState]. Sampled once per minute. olivierli@chromium.org markchang@chromium.org Instantaneous power consution in milliwatts, for the system as a whole and broken down by component. Only recorded on macOS. Only valid on Intel based systems. NB: The collection method was changed in May 2019, which may look like a regression in timeline view. {PowerConsumptionSources} minch@chromium.org xdai@chromium.org Actions performed while the power button menu is open. emaamari@google.com chromeos-commercial-identity@google.com Indicates a press of the power button, recorded when PowerManagerClient receives a signal that the power button was pressed and notifies FingerprintPowerButtonRaceDetector. minch@chromium.org xdai@chromium.org Press power button in laptop mode will result in different scenarios according to the power button up state. Counts the different power button press scenarios in laptop mode. minch@chromium.org xdai@chromium.org Press power button in tablet mode will result in different scenarios according to the power button up state. Counts the different power button press scenarios in tablet mode. bleung@chromium.org puthik@chromium.org chromeos-platform-power@google.com The maximum power supported by the connected power supply on Chrome OS. A sample is reported every time that the power manager polls sysfs (typically every 30 seconds) and sees a connected supply. Warning: this histogram was expired from 2022-04-18 to 2024-04-12; data may be missing. bleung@chromium.org puthik@chromium.org chromeos-platform-power@google.com The maximum voltage supported by the connected power supply on Chrome OS. A sample is reported every time that the power manager polls sysfs (typically every 30 seconds) and sees a connected supply. Warning: this histogram was expired from 2022-04-18 to 2024-04-12; data may be missing. mqg@chromium.org chromeos-power-team@google.com The maximum voltage supported by the connected power supply on ChromeOS. A sample is reported every time the power manager polls sysfs. Polling occurs at a regular 30-second interval and is also triggered by connecting or disconnecting a power supply. Polling is temporarily more frequent (every second) after other events such as system boot, system resume and battery saver state change. This metric is only reported on devices with Hybrid Power Boost chargers. The connected power supply includes both compatible power supply and low voltage power supply. bleung@chromium.org puthik@chromium.org chromeos-platform-power@google.com The type of the connected power supply on Chrome OS. A sample is reported every time that the power manager polls sysfs (typically every 30 seconds) and sees a connected supply. Warning: this histogram was expired from 2022-04-11 to 2024-04-12; data may be missing. mqg@chromium.org sammc@chromium.org chromeos-power-team@google.com The reason for the Chrome OS power manager shutting down or rebooting the system. Warning: this histogram was expired from 2025-06-08 to 2025-11-26; data may be missing. amoylan@chromium.org chrome-knowledge-eng@google.com Type of messages that are reported by smart charging. puthik@chromium.org chromeos-platform-power@google.com The number of suspend attempts on Chrome OS. Samples are reported before each attempt, so this histogram may include cases where the system crashed instead of suspending. puthik@chromium.org chromeos-platform-power@google.com The number of suspend attempts performed for a single suspend request (e.g. triggered by the lid being closed) that was eventually canceled on Chrome OS. This also includes requests that were canceled due to the system eventually shutting down due to repeated suspend failures. This is recorded just after the SuspendDone signal is emitted, while cleaning up from the canceled attempt. puthik@chromium.org chromeos-platform-power@google.com The number of suspend attempts performed for a single suspend request (e.g. triggered by the lid being closed) that eventually succeeded on Chrome OS. This includes the successful attempt. This is recorded after the system resumes, just after the SuspendDone signal is emitted, while unwinding the suspend preparations. niwa@chromium.org puthik@chromium.org chromeos-platform-power@google.com The amount of time powerd waited until all clients (e.g. Bluetooth Manager) to be ready to suspend after receiving a suspend request. The maximum recorded value is 60 seconds. eizan@chromium.org chromeos-power-team@google.com The results of suspend journeys on Chrome OS which might comprise multiple suspend attempts. Samples are reported after each journey. puthik@chromium.org chromeos-platform-power@google.com The results of suspend attempts on Chrome OS. Samples are reported after each attempt. kraskevich@google.com woa-performance@google.com Records errors for SystemHealthManager API calls. The SystemHealthManager API is used for computing Power.ForegroundEnergyConsumedPerScenario.30Seconds. tbroch@chromium.org Chrome OS time in minutes spent in suspend-to-RAM mode sampled at boot (i.e., the device most likely ran out of battery while in suspend). tbroch@chromium.org Chrome OS time in minutes spent in suspend-to-RAM mode sampled at resume. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com The number of times that the user adjusted the brightness during a session when on AC. Values for this metric are clamped to 10k count, so the last bucket should be considered to be including all metrics above 10k. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com The number of times that the user adjusted the brightness during a session when on battery. Values for this metric are clamped to 10k count, so the last bucket should be considered to be including all metrics above 10k. mqg@chromium.org amoylan@chromium.org chromeos-power-team@google.com The duration of a {HpsEvent}, recorded on undimming/deferring. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com What happens when UserActivityManager receives a screen dim imminent notification. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org thanhdng@chromium.org chrome-knowledge-eng@google.com What happens after screen is dimmed following model instruction. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org thanhdng@chromium.org chrome-knowledge-eng@google.com What happens after screen dim is deferred following model instruction. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org thanhdng@chromium.org chrome-knowledge-eng@google.com What happens after screen is dimmed by powerd by ignoring the model instruction. Only applicable to Chrome OS. napper@chromium.org thanhdng@chromium.org Status of logging previous idle event after a screen dim imminent signal is received. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com Records the event (various failures or success) of loading smart dim component. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com Records the type of expected version (default, experimental or empty) used by smart dim component installer. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org chrome-knowledge-eng@google.com Records the worker type that is used by smart dim ml agent to make a decision. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org pmalani@chromium.org chrome-knowledge-eng@google.com The time elapsed between a Smart Dim Inference Request being sent to the ML model, and the request being canceled before the result is returned. amoylan@chromium.org napper@chromium.org pmalani@chromium.org chrome-knowledge-eng@google.com The time elapsed between a Smart Dim Inference Request being sent to the ML model and a result being returned. amoylan@chromium.org napper@chromium.org thanhdng@chromium.org chrome-knowledge-eng@google.com This is the status code returned by the model when calculating a user inactivity score. If it is any value other than 0 (success), then some issue has occurred in the score calculation, either because preprocess was not loaded or parsed correctly, or the preprocessor failed to process a RankerExample. Only applicable to Chrome OS. amoylan@chromium.org napper@chromium.org thanhdng@chromium.org chrome-knowledge-eng@google.com The result of parsing the dim threshold parameter value. Only applicable to Chrome OS.