Ported over from previous suffix based definition where it was removed on 2021-03 now that support for Flash has been removed. 01/2022: Replaced with AllTabsHidden_VideoCapture, AllTabsHidden_Audio and AllTabsHidden_NoVideoCaptureOrAudio. fdoray@chromium.org pmonette@chromium.org catan-team@chromium.org See definition of PerformanceClass.AverageCPU8.ProcessName. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). 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. The histogram is capped at 20000 (equivalent to 2 cores fully loaded). I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. If no process of type {ProcessName} existed during the interval, a sample of zero is still emitted. Not recorded on Android. NOTE: On Windows, this is not recorded on CPUs that do not support constant rate TSC. olivierli@chromium.org catan-team@chromium.org See definition of PerformanceMonitor.EnergyImpact2.ProcessName. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). *NB: This metric will be recorded as all zeros starting in mid-October 2023 as an intermediate step towards retirement.* olivierli@chromium.org catan-team@chromium.org (Mac only) The sum of the Energy Impact of each process of the type {ProcessName}. Energy Impact is a synthetic power use estimate, as displayed in macOS Activity Monitor and the battery menu. This incorporates CPU utilization, idle wakeups, IO, and task QoS level using per-machine-model weights. Divide by 100 to match Activity Monitor's scale. Recorded 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. *NB: This metric will be recorded as all zeros starting in mid-October 2023 as an intermediate step towards retirement.* 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. fdoray@chromium.org catan-team@chromium.org Details about whether or not it's possible to get coalition resource usage data on the system. Only on macOS, recorded once at startup. fdoray@chromium.org catan-team@chromium.org The IO reads reported by the resource coalition mechanism on macOS. The data is reported as the rate per second during this interval with a byte granularity. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org The IO writes reported by the resource coalition mechanism on macOS. The data is reported as the rate per second during this interval with a byte granularity. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). Deprecated in 07/2021 because the computation was wrong. Replaced by PerformanceMonitor.ResourceCoalition.CPUTime2. sebmarchand@chromium.org catan-team@chromium.org Average CPU utilization reported by the resource coalition mechanism on macOS. 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. The histogram is capped at 20000 (equivalent to 2 cores fully loaded). I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. fdoray@chromium.org catan-team@chromium.org Average CPU utilization reported by the resource coalition mechanism on macOS. The utilization is in the 0-100% range per CPU, which is then summed up and multiplied by 100. The histogram is capped at 20000 (equivalent to 2 cores fully loaded). I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. This is recorded for {UsageScenario10sec} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org Average CPU utilization reported by the resource coalition mechanism on macOS. The utilization is in the 0-100% range per CPU, which is then summed up and multiplied by 100. The histogram is capped at 20000 (equivalent to 2 cores fully loaded). I.e. 4 cores busy at 25% each will read as 25 * 4 * 100 = 10000. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). Deprecated in 07/2021 because the name of the metric was wrong. Replaced by PerformanceMonitor.ResourceCoalition.Power. sebmarchand@chromium.org catan-team@chromium.org The energy usage reported by the resource coalition mechanism on macOS. Reported every 2 minutes. Only available on devices with an ARM CPU. siggi@chromium.org catan-team@chromium.org (Mac only) A synthetic power use estimate, as displayed in macOS Activity Monitor and the battery menu. This incorporates CPU utilization, idle wakeups, IO, and task QoS level using per-machine-model weights. Divide by 100 to match Activity Monitor's scale. Only available on macs with an Intel CPU. This EnergyImpact score is computed from the usage reported by the resource coalition mechanism on macOS. It accounts for the resource usage of all Chrome processes no matter how short-lived, as well as XPC services running on Chrome's behalf. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). Deprecated in 07/2021 because the computation was wrong. Replaced by PerformanceMonitor.ResourceCoalition.GPUTime2. sebmarchand@chromium.org catan-team@chromium.org Average GPU utilization reported by the resource coalition mechanism on macOS. Read out at each two-minute interval. The utilization is in the 0-100% range and is multiplied by 100. The histogram is capped at 10000 (equivalent to the GPU being used 100% of the time). fdoray@chromium.org catan-team@chromium.org Average GPU utilization reported by the resource coalition mechanism on macOS. The utilization is in the 0-100% range and is multiplied by 100. The histogram is capped at 10000 (equivalent to the GPU being used 100% of the time). This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org The interrupt wakeup rate reported by the resource coalition mechanism on macOS. The data is reported as the rate per second during this interval with a milliwakeup granularity. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org The platform idle wakeup rate reported by the resource coalition mechanism on macOS. The data is reported as the rate per second during this interval with a milliwakeup granularity. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org The power usage reported by the resource coalition mechanism on macOS. Only reported on devices with an ARM CPU. This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). fdoray@chromium.org catan-team@chromium.org Average CPU time spent in a given QoS level, as reported by the resource coalition mechanism on macOS. The utilization is in the 0-100% range and is multiplied by 100. The histogram is capped at 10000 (equivalent to the GPU being used 100% of the time). This is recorded every 2 minutes for {UsageScenario} (see go/chrome_power_use_per_scenario). 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. olivierli@chromium.org catan-team@chromium.org Record the usage scenario that applies to the last 10 seconds 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 "UsageScenario10Sec" 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. Removed in March 2022 without replacement. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome, split by process type as well as core type and core frequency. Currently only implemented on Android. For every second of CPU time consumed by a process on a specific CPU core type and at a specific frequency, a sample is recorded into the bucket for the frequency range. 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 for a specific process and core type across all users. Compared with Power.CpuTimeSecondsPerCoreTypeAndFrequency, the values in this histogram are approximated from more widely supported global per-CPU-core time_in_state stats, while Power.CpuTimeSecondsPerCoreTypeAndFrequency reads per-thread time_in_state stats that are only supported on newer Pixel devices (as of mid-2020). For a histogram of daily per-user values, select "Per-Client Aggregation Mode". 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 when the privacy screen is in {PrivacyScreenState} state and the device is powered by {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 mka@chromium.org chromeos-platform-power@google.com chromeos-hibernate@google.com Chrome OS battery discharge rate in mW while the system was hibernated, sampled at resume. Only reported if the system was on battery power both before hibernating and after resuming, if the energy level didn't increase while hibernated (which would indicate that an AC adapter was connected), and if the system was hibernated for at least a minute. 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. mka@chromium.org bgeffon@chromium.org chromeos-platform-power@google.com chromeos-hibernate@google.com The battery level in percent at the time the system entered hibernate. Reported at resume from hibernate. 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. tbroch@chromium.org Chrome OS remaining battery charge as percent of the maximum battery charge, sampled at the end of a user session when the device is on AC. puthik@chromium.org chromeos-platform-power@google.com Chrome OS remaining battery charge as percent of the maximum battery charge, sampled at the end of a user session when the device is on battery. puthik@chromium.org chromeos-platform-power@google.com Chrome OS remaining battery charge as percent of the maximum battery charge, sampled at the start of a user session when the device is on AC. tbroch@chromium.org Chrome OS remaining battery charge as percent of the maximum battery charge, sampled at the start of a user session when the device is on battery. cwd@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. dianders@chromium.org Chrome OS (Snow RO firmware 2695.90.0 only) number of 8K chunks that were fixed (memory corruption corrected) for each suspend/resume cycle. Expect 0 around 97% of the time and a non-zero value around 3% of the time. dianders@chromium.org Chrome OS (Snow RO firmware 2695.90.0 only) number of 4-byte words that were fixed (memory corruption corrected) for each suspend/resume cycle. Expect 0 around 97% of the time and a non-zero value around 3% of the time. Would be exactly equal to Power.BitfixChunks if there were only one corrupted word in each chunk but is sometimes several times higher. Deprecated in 03/2022 because the Power Scheduler feature did not launch. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com For clients enrolled in CPU affinity restriction experiments (e.g. restricting execution to little cores only), records the new CPU affinity for a process every time it is changed, provided it was succcessfully set. Deprecated in 03/2022 because the Power Scheduler feature did not launch. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com For clients enrolled in CPU affinity restriction experiments (e.g. restricting execution to little cores only), records whether the CPU affinity for a process could be succcessfully set. Removed in March 2022 without replacement. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome, split by process type as well as core type and core frequency. Currently only implemented on Android. For every second of CPU time consumed by a process on a specific CPU core type and at a specific frequency, a sample is recorded into the bucket for the frequency range. 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 for a specific process and core type across all users. For a histogram of daily per-user values, select "Per-Client Aggregation Mode". Deprecated in 11/2022 without replacement. eseckler@chromium.org oksamyt@chromium.org woa-performance@google.com Total seconds of CPU time consumed by Chrome's {ProcessType} process, split by power mode. Currently only implemented on Android. For every second of CPU time consumed by the process, while a specific PowerMode was active, a sample is recorded into the bucket for the PowerMode. 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 PowerMode within all {ProcessType} processes 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, 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". michaelbai@chromium.org pdr@chromium.org peter@chromium.org Whether the primary main document has an inferred dark color scheme. Emitted each time WebContents infers a new non-empty color scheme. chirantan@chromium.org abhishekbh@chromium.org ravisadineni@chromium.org The amount of time a system spent awake every time it woke up in dark resume. chirantan@chromium.org abhishekbh@chromium.org ravisadineni@chromium.org The amount of time a system spent awake every time it woke up in dark resume triggered by an unknown or unsupported wake trigger. chirantan@chromium.org abhishekbh@chromium.org ravisadineni@chromium.org The amount of time a system spent awake every time it woke up in dark resume triggered by a WiFi disconnect. chirantan@chromium.org abhishekbh@chromium.org ravisadineni@chromium.org The amount of time a system spent awake every time it woke up in dark resume triggered by a WiFi packet pattern match. chirantan@chromium.org abhishekbh@chromium.org ravisadineni@chromium.org The amount of time a system spent awake every time it woke up in dark resume triggered by a net detect SSID match. mqg@chromium.org charleszhao@chromium.org 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. puthik@chromium.org chromeos-platform-power@google.com The result of requesting an external display's brightness on Chrome OS. A request is sent when the user presses a brightness key and the current brightness is not already cached. A successful request is followed shortly thereafter by a read attempt. puthik@chromium.org chromeos-platform-power@google.com The result of attempting to change an external display's brightness on Chrome OS. A request is sent when the user presses a brightness key and the current brightness is either already cached or successfully loaded. puthik@chromium.org chromeos-platform-power@google.com The time that the firmware took to resume the Chrome OS device from suspend-to-RAM state when running on AC at pre-suspend time. puthik@chromium.org chromeos-platform-power@google.com The time that the firmware took to resume the Chrome OS device from suspend-to-RAM state when running on battery at pre-suspend time. 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). 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. carlscab@google.com eseckler@chromium.org khokhlov@google.com woa-performance@google.com Recorded every time the device thermal state changes while Chrome is a foreground app. Only supported on Android. 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. puthik@chromium.org mka@chromium.org chromeos-platform-power@google.com chromeos-hibernate@google.com The number of hibernate attempts performed for a single hibernate request (e.g. triggered by transition from suspend to hibernation) that was eventually canceled on Chrome OS. This also includes requests that were canceled due to the system eventually shutting down due to repeated hibernation failures. This is recorded just after the SuspendDone signal is emitted, while cleaning up from the canceled attempt. puthik@chromium.org mka@chromium.org chromeos-platform-power@google.com chromeos-hibernate@google.com The number of hibernation attempts performed for a single hibernation request (e.g. triggered by transition from suspend to hibernation) 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. Deprecated in 11/2022 without replacement. eseckler@chromium.org khokhlov@chromium.org woa-performance@google.com Records the average CPU load caused by the corresponding process over the last 5 sec (or more) of Idle power mode. Emitted at the end of each such period, so not more often that once in 5 sec. Note that CPU load can be greater than 100% on milti-core systems. tbroch@chromium.org napper@chromium.org Chrome OS user idle time since the screen dimmed sampled when the user becomes active again if the device runs on AC. tbroch@chromium.org napper@chromium.org Chrome OS user idle time since the screen dimmed sampled when the user becomes active again if the device runs on battery. tbroch@chromium.org napper@chromium.org Chrome OS user idle time since the screen turned off sampled when the user becomes active again if the device runs on AC. tbroch@chromium.org napper@chromium.org Chrome OS user idle time since the screen turned off sampled when the user becomes active again if the device runs on battery. tbroch@chromium.org napper@chromium.org Chrome OS user idle time sampled when the user becomes active again if the device runs on AC. tbroch@chromium.org napper@chromium.org Chrome OS user idle time sampled when the user becomes active again if the device runs on battery. 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 chromeos-platform-power@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. tbroch@chromium.org 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. tbroch@chromium.org The time that the kernel took to suspend-to-RAM the Chrome OS device when running on AC. puthik@chromium.org chromeos-platform-power@google.com The time that the kernel took to suspend-to-RAM the Chrome OS device when running on battery. tbroch@chromium.org The level of the keyboard backlight as a percentage. Sampled every 30 seconds. mqg@chromium.org charleszhao@chromium.org 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. 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. avi@chromium.org lgrey@chromium.org Whether the user's machine is on battery power. Sampled once per minute. Unlike Power.Mac.IsOnBattery, this correctly logs desktop Macs as not being on battery. lgrey@chromium.org olivierli@chromium.org Thermal state of the user's machine as reported by macOS's [NSProcessInfo thermalState]. Sampled once per minute. puthik@chromium.org chromeos-platform-power@google.com Reasons why power-management-related daily metrics were reported. Chrome OS only. skardach@google.com svenva@google.com chromeos-platform-power@google.com Reports the time a Chrome OS device spends in the S0ix idle state while not suspended (that is between system resume and suspend events) as a percentage of the time spent in the Package C10 (PC10) idle state. Reported only if at the time of measurement the time spent in PC10 is non-zero. Data points for this metric are recorded on every resume and suspend event and therefore the metric itself is reported on every suspend attempt, starting from the second one. Only available on Chrome OS devices with Intel CPU. skardach@google.com svenva@google.com chromeos-platform-power@google.com Reports the time a Chrome OS device spends in the Package C10 (PC10) idle state as a percentage of the time device is not suspended (that is between system resume and suspend events). Reported even if the value is zero. Data points for this metric are recorded on every resume and suspend event and therefore the metric itself is reported on every suspend attempt, starting from the second one. Only available on Chrome OS devices with Intel CPU. skyostil@chromium.org chromeos-platform-power@google.com The amount of wall time in milliseconds taken to fail a read of the battery capacity of a peripheral. skyostil@chromium.org chromeos-platform-power@google.com The amount of wall time in milliseconds taken to complete a read of the battery capacity of a peripheral. puthik@chromium.org chromeos-platform-power@google.com The amount of time between the user pressing the power button and Chrome acknowledging the button-down event on Chrome OS. Values for this metric are capped to two seconds. 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. Deprecated in 11/2022 without replacement. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Records the new value of the {ProcessType} process power mode every time a change is detected (happens on the order of once per second). Deprecated in 03/2022 because the Power Scheduler feature did not launch. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Duration during which CPU throttling was active. Only recorded when a CPU throttling policy is active (e.g. throttle while idle). A sample is recorded every time throttling stops (e.g. when exiting idle state). Deprecated in 03/2022 because the Power Scheduler feature did not launch. eseckler@chromium.org skyostil@chromium.org woa-performance@google.com Duration in milliseconds during which CPU throttling was active, split by the CPU affinity for that duration. Only recorded when a CPU throttling policy is active (e.g. throttle while idle). A sample is recorded every time throttling stops (e.g. when exiting idle state), on the order of once per second. tbroch@chromium.org The reason for the Chrome OS power manager shutting down or rebooting the system. thanhdng@chromium.org napper@chromium.org 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. puthik@chromium.org chromeos-platform-power@google.com The results of suspend attempts on Chrome OS. Samples are reported after each attempt. 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. tbroch@chromium.org napper@chromium.org 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. tbroch@chromium.org napper@chromium.org 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 charleszhao@chromium.org The duration of a {HpsEvent}, recorded on undimming/deferring. napper@chromium.org thanhdng@chromium.org What happens when UserActivityManager receives a screen dim imminent notification. Only applicable to Chrome OS. napper@chromium.org thanhdng@chromium.org What happens after screen is dimmed following model instruction. Only applicable to Chrome OS. napper@chromium.org thanhdng@chromium.org What happens after screen dim is deferred following model instruction. Only applicable to Chrome OS. napper@chromium.org thanhdng@chromium.org 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. alanlxl@chromium.org amoylan@chromium.org napper@chromium.org Records the event (various failures or success) of loading smart dim component. Only applicable to Chrome OS. alanlxl@chromium.org amoylan@chromium.org napper@chromium.org Records the type of expected version (default, experimental or empty) used by smart dim component installer. Only applicable to Chrome OS. alanlxl@chromium.org amoylan@chromium.org napper@chromium.org Records the worker type that is used by smart dim ml agent to make a decision. Only applicable to Chrome OS. Kept because it's used in tast power.SmartDim. alanlxl@chromium.org amoylan@chromium.org napper@chromium.org The source of web page info in smart dim features, emitted everytime smart dim is requested. amoylan@chromium.org napper@chromium.org napper@chromium.org pmalani@chromium.org 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 napper@chromium.org pmalani@chromium.org The time elapsed between a Smart Dim Inference Request being sent to the ML model and a result being returned. napper@chromium.org thanhdng@chromium.org 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. napper@chromium.org thanhdng@chromium.org The result of parsing the dim threshold parameter value. Only applicable to Chrome OS.