OLD | NEW |
1 Copyright (c) 2010 The Chromium OS Authors. All rights reserved. | 1 Copyright (c) 2010 The Chromium OS Authors. All rights reserved. |
2 Use of this source code is governed by a BSD-style license that can be | 2 Use of this source code is governed by a BSD-style license that can be |
3 found in the LICENSE file. | 3 found in the LICENSE file. |
4 | 4 |
5 The Chrome OS "metrics" package contains utilities for client-side | 5 The Chrome OS "metrics" package contains utilities for client-side |
6 user metric collection. The collected data is sent to Chrome for | 6 user metric collection. The collected data is sent to Chrome for |
7 transport to the UMA server. | 7 transport to the UMA server. |
8 | 8 |
9 | 9 |
10 ================================================================================ | 10 ================================================================================ |
(...skipping 98 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
109 screen saver states to determine if the user is actively using the | 109 screen saver states to determine if the user is actively using the |
110 device or not and generates the corresponding data. The metrics daemon | 110 device or not and generates the corresponding data. The metrics daemon |
111 uses libmetrics to send the data to Chrome. | 111 uses libmetrics to send the data to Chrome. |
112 | 112 |
113 The recommended way to generate metrics data from a module is to link | 113 The recommended way to generate metrics data from a module is to link |
114 and use libmetrics directly. However, the module could instead send | 114 and use libmetrics directly. However, the module could instead send |
115 signals to or communicate in some alternative way with the metrics | 115 signals to or communicate in some alternative way with the metrics |
116 daemon. Then the metrics daemon needs to monitor for the relevant | 116 daemon. Then the metrics daemon needs to monitor for the relevant |
117 events and take appropriate action -- for example, aggregate data and | 117 events and take appropriate action -- for example, aggregate data and |
118 send the histogram samples. | 118 send the histogram samples. |
| 119 |
| 120 |
| 121 ================================================================================ |
| 122 FAQ |
| 123 ================================================================================ |
| 124 |
| 125 Q. What should my histogram's |min| and |max| values be set at? |
| 126 |
| 127 A. You should set the values to a range that covers the vast majority |
| 128 of samples that would appear in the field. Note that samples below |
| 129 the |min| will still be collected in the underflow bucket and |
| 130 samples above the |max| will end up in the overflow bucket. Also, |
| 131 the reported mean of the data will be correct regardless of the |
| 132 range. |
| 133 |
| 134 Q. How many buckets should I use in my histogram? |
| 135 |
| 136 A. You should allocate as many buckets as necessary to perform proper |
| 137 analysis on the collected data. Note, however, that the memory |
| 138 allocated in Chrome for each histogram is proportional to the |
| 139 number of buckets. Therefore, it is strongly recommended to keep |
| 140 this number low (e.g., 50 is normal, while 100 is probably high). |
| 141 |
| 142 Q. When should I use an enumeration (linear) histogram vs. a regular |
| 143 (exponential) histogram? |
| 144 |
| 145 A. Enumeration histograms should really be used only for sampling |
| 146 enumerated events and, in some cases, percentages. Normally, you |
| 147 should use a regular histogram with exponential bucket layout that |
| 148 provides higher resolution at the low end of the range and lower |
| 149 resolution at the high end. Regular histograms are generally used |
| 150 for collecting performance data (e.g., timing, memory usage, power) |
| 151 as well as aggregated event counts. |
OLD | NEW |