All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=697098

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpKCbtgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpPbTowkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpIn4uQoM


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus4-lollipop
webrtc-android-tests-nexus5-kitkat

It looks like the spike went down, without any WebRTC changes. Could it be something in chromium that was changed and reverted? Nothing stands out to me though.

If something in chrome changed, then there ought to be a chromium roll in the blame list.

There is a chromium roll the CL before yours, and (for other reasons) I suspect that it might cause some performance changes. In this case, however, it is quite clear that the metrics don't increase until your CL is included. If it turns out to be the chromium CL, then we need to file a bug against the perf dashboard/infrastructure.

Could this bug explain the regression? https://bugs.chromium.org/p/webrtc/issues/detail?id=7259

The spike went down when it was fixed. And the ramp up/down tests do use FakeNetworkPipe.

Anything's possible I suppose, but what triggered the regression? The FakeNetworkPipe flaw has been there pretty much forever. Tommi recently made some changes that exposed the problem, but I don't see him landing any CLs in the vicinity of the increase.

Besides, on the kitkat bot, the regression recovered when we rolled a new chromium way before the FakeNetworkPipe CL.

Hmm, I don't know then. I'll remove myself as owner because I don't think the NULL/nullptr CL is related. How can we manually re-run the performance bots to see if these results are repeatable? I'm having trouble finding that information on our wiki.

Removing R-V-G label (was set upon bug filing because the bot was incorrectly configured as internal)

Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.