Add UMA/Telemetry stats for touch event latency

Add UMA/Telemetry stats for touch event latency
    
This CL adds following UMA stats for touch event latency
1. Event.Latency.Browser.TouchUI:
   touch event received by Chrome -> touch event sent to renderer
    
2. Event.Latency.Browser.TouchAcked
   touch event sent to renderer -> touch event acked from renderer
    
Corresponding telemetry stats are also added.
    
BUG=chromium:246034
TEST=1. Check UMA stats exist in chrome://histograms/Event.Latency.Browser
     2. Check the relevant stats are in telemetry smoothness test.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=209255

[jbauman, 2013-06-26 08:52:53]

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2577: LatencyIter ui_it
= latency_map.find(std::make_pair(
Is it guaranteed that there will be at most one
INPUT_EVENT_LATENCY_UI_COMPONENT, INPUT_EVENT_LATENCY_RWH_COMPONENT, and
INPUT_EVENT_LATENCY_ACKED_COMPONENT that contributes to a LatencyInfo? E.g.
we'll never coalesce two LatencyInfos that each contain one of these? If so, you
should add a DCHECK that the event_count == 1 for these. If not, this logic is
likely to be wrong, because the latency calculations won't make sense.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
This is kind of weird, because we're making a histogram from the averaged
latency between all the input events that contributed to this. But I guess it
might work for you.

[Rick Byers, 2013-06-26 16:34:55]

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2574: LatencyIter
original_it = latency_map.find(std::make_pair(
I think it would be a little cleaner to add a LatencyInfo::Lookup API that
returns a reference to the entry with the given component+id.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2575:
ui::INPUT_EVENT_LATENCY_ORIGINAL_COMPONENT, 0));
Are we guaranteed to have this (eg. for synthetic events)?  I'd prefer to skip
reporting metrics when we don't have reliable data, then to try to ensure we've
always got values even when that means putting some fake value in (i.e. the
timestamp the event was created in software).

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
On 2013/06/26 08:52:53, jbauman wrote:
> This is kind of weird, because we're making a histogram from the averaged
> latency between all the input events that contributed to this. But I guess it
> might work for you.

Yeah, I'm very worried about relying on these averaged timestamps.  One option
is to report the histogram only when the event_count is 1, but then I'd also
want some assurance that that is representative (eg. another histogram showing
that >50% of the time we have only 1 event).

Alternately we could always report histograms for pairs of time points that
don't have coalescing between them (i.e. send the UMA when the 2nd element in
the pair is added to the LatencyInfo).

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
Isn't Event.Latency.Touch.System basically the same as our existing
Event.Latency.Browser.ET_TOUCH_MOVED?  I'm not opposed to having some redundancy
(eg. to validate that LatencyInfo agrees with our existing measures), but I
don't see much additional value.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2611:
UMA_HISTOGRAM_CUSTOM_COUNTS(
It would be cleaner to use a common macro for all of these.  I think Varun had a
CL up that added UMA_HISTOGRAM_SHORT_TIMES.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2646:
"Event.Latency.Touch.Acked_No_Consumer_Exists",
Separating out the metrics into the 3 ACK states is an interesting idea.  I'm
not convinced we'll learn something interesting, but we can give it a shot and
see what we learn.  Perhaps update the touch scroll latency doc with your ideas
here?

https://codereview.chromium.org/17757002/diff/1/tools/perf/measurements/smoot...
File tools/perf/measurements/smoothness.py (right):

https://codereview.chromium.org/17757002/diff/1/tools/perf/measurements/smoot...
tools/perf/measurements/smoothness.py:201:
results.Add('average_touch_acked_no_consumer_latency', 'ms', averageLatency,
this is all pretty repetative, perhaps avoid duplication and reducing the number
of lines with a helper function?

[Yufeng Shen (Slow to review), 2013-06-26 20:44:05]

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2574: LatencyIter
original_it = latency_map.find(std::make_pair(
On 2013/06/26 16:34:55, Rick Byers wrote:
> I think it would be a little cleaner to add a LatencyInfo::Lookup API that
> returns a reference to the entry with the given component+id.

Done.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2575:
ui::INPUT_EVENT_LATENCY_ORIGINAL_COMPONENT, 0));
On 2013/06/26 16:34:55, Rick Byers wrote:
> Are we guaranteed to have this (eg. for synthetic events)?  I'd prefer to skip
> reporting metrics when we don't have reliable data, then to try to ensure
we've
> always got values even when that means putting some fake value in (i.e. the
> timestamp the event was created in software).

Done.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2577: LatencyIter ui_it
= latency_map.find(std::make_pair(
On 2013/06/26 08:52:53, jbauman wrote:
> Is it guaranteed that there will be at most one
> INPUT_EVENT_LATENCY_UI_COMPONENT, INPUT_EVENT_LATENCY_RWH_COMPONENT, and
> INPUT_EVENT_LATENCY_ACKED_COMPONENT that contributes to a LatencyInfo? E.g.
> we'll never coalesce two LatencyInfos that each contain one of these? If so,
you
> should add a DCHECK that the event_count == 1 for these. If not, this logic is
> likely to be wrong, because the latency calculations won't make sense.

This should be true. This function, ComputeTouchLatency(), is called on
TouchEvent that are not coalesced. So the the latency info for the touch event
should have exactly 1 INPUT_EVENT_LATENCY_UI_COMPONENT,
INPUT_EVENT_LATENCY_RWH_COMPONENT and INPUT_EVENT_LATENCY_ACKED_COMPONENT.
A DCHECK() is added.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
On 2013/06/26 16:34:55, Rick Byers wrote:
> Isn't Event.Latency.Touch.System basically the same as our existing
> Event.Latency.Browser.ET_TOUCH_MOVED?  I'm not opposed to having some
redundancy
> (eg. to validate that LatencyInfo agrees with our existing measures), but I
> don't see much additional value.

removed.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
On 2013/06/26 08:52:53, jbauman wrote:
> This is kind of weird, because we're making a histogram from the averaged
> latency between all the input events that contributed to this. But I guess it
> might work for you.

As comment above, there is no coalesce or latency info merge happening when
this function is called, so the histogram should be truly from individual
samples.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
On 2013/06/26 16:34:55, Rick Byers wrote:
> On 2013/06/26 08:52:53, jbauman wrote:
> > This is kind of weird, because we're making a histogram from the averaged
> > latency between all the input events that contributed to this. But I guess
it
> > might work for you.
> 
> Yeah, I'm very worried about relying on these averaged timestamps.  One option
> is to report the histogram only when the event_count is 1, but then I'd also
> want some assurance that that is representative (eg. another histogram showing
> that >50% of the time we have only 1 event).
> 
> Alternately we could always report histograms for pairs of time points that
> don't have coalescing between them (i.e. send the UMA when the 2nd element in
> the pair is added to the LatencyInfo).

I think it is already taking the alternative approach you suggested.
This function is called right after the ACKED_XXX_COMPONENT is added to
the latency info, and as comments to John's question that there is no
average for UI/RWH_COMPONENT

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2611:
UMA_HISTOGRAM_CUSTOM_COUNTS(
On 2013/06/26 16:34:55, Rick Byers wrote:
> It would be cleaner to use a common macro for all of these.  I think Varun had
a
> CL up that added UMA_HISTOGRAM_SHORT_TIMES.

As the reviewer for his CL points out that there is resolution issue with
UMA_HISTOGRAM_SHORT_TIMES, particularly when you adding sample using TimeDelta,
only the milliseconds are extracted from TimeDelta. That's why
I am using  UMA_HISTOGRAM_CUSTOM_COUNTS() to take out the microseconds from
sample instead of UMA_HISTOGRAM_CUSTOM_TIMES().

We will see. If varun can resolve the issue before this CL passed review, I will
change to his macro.

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2646:
"Event.Latency.Touch.Acked_No_Consumer_Exists",
On 2013/06/26 16:34:55, Rick Byers wrote:
> Separating out the metrics into the 3 ACK states is an interesting idea.  I'm
> not convinced we'll learn something interesting, but we can give it a shot and
> see what we learn.  Perhaps update the touch scroll latency doc with your
ideas
> here?

will do

https://codereview.chromium.org/17757002/diff/1/tools/perf/measurements/smoot...
File tools/perf/measurements/smoothness.py (right):

https://codereview.chromium.org/17757002/diff/1/tools/perf/measurements/smoot...
tools/perf/measurements/smoothness.py:201:
results.Add('average_touch_acked_no_consumer_latency', 'ms', averageLatency,
On 2013/06/26 16:34:55, Rick Byers wrote:
> this is all pretty repetative, perhaps avoid duplication and reducing the
number
> of lines with a helper function?

Done.

[Rick Byers, 2013-06-26 21:42:10]

LGTM (but a few minor suggestions).

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/1/content/browser/renderer_host...
content/browser/renderer_host/render_widget_host_impl.cc:2601:
"Event.Latency.Touch.System",
On 2013/06/26 20:44:05, Yufeng Shen wrote:
> On 2013/06/26 16:34:55, Rick Byers wrote:
> > On 2013/06/26 08:52:53, jbauman wrote:
> > > This is kind of weird, because we're making a histogram from the averaged
> > > latency between all the input events that contributed to this. But I guess
> it
> > > might work for you.
> > 
> > Yeah, I'm very worried about relying on these averaged timestamps.  One
option
> > is to report the histogram only when the event_count is 1, but then I'd also
> > want some assurance that that is representative (eg. another histogram
showing
> > that >50% of the time we have only 1 event).
> > 
> > Alternately we could always report histograms for pairs of time points that
> > don't have coalescing between them (i.e. send the UMA when the 2nd element
in
> > the pair is added to the LatencyInfo).
> 
> I think it is already taking the alternative approach you suggested.
> This function is called right after the ACKED_XXX_COMPONENT is added to
> the latency info, and as comments to John's question that there is no
> average for UI/RWH_COMPONENT 

Ah, sorry - perfect, thanks!

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2614:
rendering_stats_.total_touch_acked_consumed_latency += acked_delta;
you could probably make this code more concise by flattening all 3 cases into
one with 3-element arrays in rendering_stats and an enum which chooses which
arrays to update and which string to use for the UMA metric.

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2619: 100000,
100ms might be too short, especially on Android.  Suggest using 1s as the upper
bound instead.

https://codereview.chromium.org/17757002/diff/7001/ui/base/latency_info.h
File ui/base/latency_info.h (right):

https://codereview.chromium.org/17757002/diff/7001/ui/base/latency_info.h#new...
ui/base/latency_info.h:68: LatencyMap::const_iterator
GetLatencyComponent(LatencyComponentType type,
Rather than return an iterator, may be easier to use as:
bool GetLatencyComponent(LatencyComponentType type, int64 id, LatencyComponent&
output) ??

[Yufeng Shen (Slow to review), 2013-06-26 23:02:26]

Hi Rick,

I made some additional changes:
1) Change to use only one metric for touch event ack latency
2) Change the UMA name to be Event.Latency.Browser.TouchUI/TouchAcked to be
   consistent with what we are already using.

PTAL, thanks.

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2614:
rendering_stats_.total_touch_acked_consumed_latency += acked_delta;
On 2013/06/26 21:42:10, Rick Byers wrote:
> you could probably make this code more concise by flattening all 3 cases into
> one with 3-element arrays in rendering_stats and an enum which chooses which
> arrays to update and which string to use for the UMA metric.

After a second thought, I find I don't have strong justification for having
stats for 3 different ack response and it unnecessarily complicated. So I
changed it to be just one metric just for acked touch event latency.

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2614:
rendering_stats_.total_touch_acked_consumed_latency += acked_delta;
On 2013/06/26 21:42:10, Rick Byers wrote:
> you could probably make this code more concise by flattening all 3 cases into
> one with 3-element arrays in rendering_stats and an enum which chooses which
> arrays to update and which string to use for the UMA metric.

After a second thought, I find I have no strong justification for
having stats for 3 different ack responses and it unnecessarily makes code
complicated. So I change to just use one metric for touch event ack latency.

https://codereview.chromium.org/17757002/diff/7001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2619: 100000,
On 2013/06/26 21:42:10, Rick Byers wrote:
> 100ms might be too short, especially on Android.  Suggest using 1s as the
upper
> bound instead.

Done.

https://codereview.chromium.org/17757002/diff/7001/ui/base/latency_info.h
File ui/base/latency_info.h (right):

https://codereview.chromium.org/17757002/diff/7001/ui/base/latency_info.h#new...
ui/base/latency_info.h:68: LatencyMap::const_iterator
GetLatencyComponent(LatencyComponentType type,
On 2013/06/26 21:42:10, Rick Byers wrote:
> Rather than return an iterator, may be easier to use as:
> bool GetLatencyComponent(LatencyComponentType type, int64 id,
LatencyComponent&
> output) ??

Done.

[jbauman, 2013-06-26 23:07:55]

lgtm

[Rick Byers, 2013-06-27 00:21:25]

Nice, I think this simplicity is better for now - we can always expand it later
if we think we'll learn something.  LGTM.

[sadrul, 2013-06-27 17:44:01]

[ please merge with the changes that landed last night ]

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2596:
latency_info.FindLatency(ui::INPUT_EVENT_LATENCY_ACKED_COMPONENT,
Check return value of FindLatency

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_aura.cc:1806:
host_->ComputeTouchLatency(*((*iter)->latency()));
Why is this called from here? Why not from
RWHI::OnInputEventAck/ProcessTouchAck?

https://codereview.chromium.org/17757002/diff/13001/ui/base/latency_info.h
File ui/base/latency_info.h (right):

https://codereview.chromium.org/17757002/diff/13001/ui/base/latency_info.h#ne...
ui/base/latency_info.h:69: bool FindLatency(LatencyComponentType type,
Merge this with HasLatency

[Yufeng Shen (Slow to review), 2013-06-27 19:01:02]

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2596:
latency_info.FindLatency(ui::INPUT_EVENT_LATENCY_ACKED_COMPONENT,
On 2013/06/27 17:44:01, sadrul wrote:
> Check return value of FindLatency

Done.

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/17757002/diff/13001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_view_aura.cc:1806:
host_->ComputeTouchLatency(*((*iter)->latency()));
On 2013/06/27 17:44:01, sadrul wrote:
> Why is this called from here? Why not from
> RWHI::OnInputEventAck/ProcessTouchAck?

right, it is better to be in RWHI or touch_event_queue so we don't need to
do this for each view port.

Since we want to add the ACKED_COMPONENT for each uncoalesced (Web/UI)touch
event so I feel it is proper to do it in TouchEventQueue::PopTouchEventToView()
where we extract each individual touch event out and before calling view's
ProcessAckedTouchEvent.
So move the code to TouchEventQueue::PopTouchEventToView().

https://codereview.chromium.org/17757002/diff/13001/ui/base/latency_info.h
File ui/base/latency_info.h (right):

https://codereview.chromium.org/17757002/diff/13001/ui/base/latency_info.h#ne...
ui/base/latency_info.h:69: bool FindLatency(LatencyComponentType type,
On 2013/06/27 17:44:01, sadrul wrote:
> Merge this with HasLatency

Done.

[sadrul, 2013-06-27 22:40:11]

I am not familiar with the BrowserRenderingStats/message related changes. The
rest of the code LGTM

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2617:
if(!latency_info.FindLatency(ui::INPUT_EVENT_LATENCY_ACKED_COMPONENT,
ifspace(

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2620: return;
Do you not want to send the IPC below in this case (because you are changing
some bits of |rendering_stats_| above)?

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2635: Send(new
ViewMsg_SetBrowserRenderingStats(routing_id_, rendering_stats_));
I don't know what this does. I will leave this part for jbauman@ to review.

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
File content/browser/renderer_host/touch_event_queue.cc (right):

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/touch_event_queue.cc:190: for
(WebTouchEventWithLatencyList::const_iterator iter = acked_event->begin(),
You probably can just use an iterator here instead of a const_iterator, and then
not have to do the const_cast below.

[Yufeng Shen (Slow to review), 2013-06-27 23:44:06]

cc dtu@ for OWNER on 
tools/perf/measurements/

cc jln@ for OWNER on
content/common/

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2617:
if(!latency_info.FindLatency(ui::INPUT_EVENT_LATENCY_ACKED_COMPONENT,
On 2013/06/27 22:40:12, sadrul wrote:
> ifspace(

Done.

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2620: return;
On 2013/06/27 22:40:12, sadrul wrote:
> Do you not want to send the IPC below in this case (because you are changing
> some bits of |rendering_stats_| above)?

right, done.

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
File content/browser/renderer_host/touch_event_queue.cc (right):

https://codereview.chromium.org/17757002/diff/28001/content/browser/renderer_...
content/browser/renderer_host/touch_event_queue.cc:190: for
(WebTouchEventWithLatencyList::const_iterator iter = acked_event->begin(),
On 2013/06/27 22:40:12, sadrul wrote:
> You probably can just use an iterator here instead of a const_iterator, and
then
> not have to do the const_cast below.

begin() only returns const_iterator so we have to do the const_cast anyway or we
add a non-const version of begin().

[jln (very slow on Chromium), 2013-06-28 00:41:52]

On 2013/06/27 23:44:06, Yufeng Shen wrote:
> cc dtu@ for OWNER on 
> tools/perf/measurements/
> 
> cc jln@ for OWNER on
> content/common/

You need a content/ owner, but I'll take a look at
content/common/view_messages.h

[jln (very slow on Chromium), 2013-06-28 00:43:32]

content/common/view_messages.h lgtm

[dtu, 2013-06-28 18:04:48]

telemetry OWNERS lgtm

[commit-bot: I haz the power, 2013-06-28 18:05:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miletus@chromium.org/17757002/34001

[commit-bot: I haz the power, 2013-06-28 18:35:05]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[commit-bot: I haz the power, 2013-06-28 18:55:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miletus@chromium.org/17757002/34001

[commit-bot: I haz the power, 2013-06-28 23:52:26]

Retried try job too often on win_rel for step(s) chrome_frame_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-29 00:32:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miletus@chromium.org/17757002/34001

[commit-bot: I haz the power, 2013-06-29 01:22:23]

Change committed as 209255