Updated device reporting code to report multiple samples of free RAM

Updated device reporting code to report multiple samples of free RAM

DeviceStatusCollector used to report multiple CPU usage measurements, but only a
single free-RAM measurement. This CL changes the reporting code to report
multiple free-RAM measurements.

BUG=430908
Committed: https://crrev.com/98a27f88bdc818fb1b2c3e5a96e17581380b4046
Cr-Commit-Position: refs/heads/master@{#313681}

[Andrew T Wilson (Slow), 2015-01-28 15:45:52]

atwilson@chromium.org changed reviewers:
+ mnissler@chromium.org

[Andrew T Wilson (Slow), 2015-01-28 15:45:52]

PTAL - I know you're busy, but since you reviewed the previous CL that
implemented RAM reporting, I figured you should also review this one.

[Mattias Nissler (ping if slow), 2015-01-29 08:19:41]

Code-wise LGTM. Not sure whether this makes sense from the server perspective
though, see my comment.

https://codereview.chromium.org/884063003/diff/1/chrome/browser/chromeos/poli...
File chrome/browser/chromeos/policy/device_status_collector.cc (right):

https://codereview.chromium.org/884063003/diff/1/chrome/browser/chromeos/poli...
chrome/browser/chromeos/policy/device_status_collector.cc:424:
resource_usage_.pop_front();
Hm, this seems odd from a reporting perspective. There are no timestamps
attached to the samples, so the server doesn't know when these samples were
collected. Also, depending on the reporting frequency, samples may be reported
multiple times to the server or never. Is this intentional?

[Andrew T Wilson (Slow), 2015-01-29 09:02:58]

https://codereview.chromium.org/884063003/diff/1/chrome/browser/chromeos/poli...
File chrome/browser/chromeos/policy/device_status_collector.cc (right):

https://codereview.chromium.org/884063003/diff/1/chrome/browser/chromeos/poli...
chrome/browser/chromeos/policy/device_status_collector.cc:424:
resource_usage_.pop_front();
On 2015/01/29 08:19:41, Mattias Nissler wrote:
> Hm, this seems odd from a reporting perspective. There are no timestamps
> attached to the samples, so the server doesn't know when these samples were
> collected. Also, depending on the reporting frequency, samples may be reported
> multiple times to the server or never. Is this intentional?

Yes, the goal isn't to give a smooth set of discrete datapoints to the server
(for example, two simultaneous status uploads will upload overlapping data, and
if the status upload period is very long, you won't get samples for the entire
period between uploads because we cap the # samples).

Basically, the genesis of this is Matt's desire for us to upload an "average" of
CPU usage. Rather than compute that average on the client, we decided to send
the CPU usage samples to the server and let them do what they want with it
(compute average, maybe compute min/max).

Then Bin noticed that we weren't sending up samples for RAM, and wanted to know
why not - it might be useful to be able to display high/low water marks for RAM,
etc, similar to what we do for CPU. Most likely they'll just do something really
simple with the RAM samples (like display average).

The goal here is explicitly *not* to provide timestamps so the user can 
historically look at the data and say "Oh, there was a CPU spike at 1AM last
night".

If it ends up being useful in the future, timestamps are something we can add.

[Andrew T Wilson (Slow), 2015-01-29 09:03:01]

The CQ bit was checked by atwilson@chromium.org

[commit-bot: I haz the power, 2015-01-29 09:03:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/884063003/1

[commit-bot: I haz the power, 2015-01-29 09:07:13]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-01-29 09:12:19]

Patchset 1 (id:??) landed as
https://crrev.com/98a27f88bdc818fb1b2c3e5a96e17581380b4046
Cr-Commit-Position: refs/heads/master@{#313681}