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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgoMTyngkM


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

webrtc-linux-large-tests

Hi, this is a small but reasonable clear performance change, which seem to be related with your cl https://codereview.webrtc.org/2589713003. Can you have a look?

It's unclear to me what the test means, I couldn't find it in the list referenced
from the perf sheriff document. 

Other nearby cls are https://codereview.webrtc.org/2623513002 and https://codereview.webrtc.org/2625893004

I don't think its related to https://codereview.webrtc.org/2589713003 since the NetEQ test shouldn't have FlexFEC enabled. Same goes for https://codereview.webrtc.org/2623513002.

https://codereview.webrtc.org/2625893004 also looks pretty harmless to me, since I think the target bitrate feedback message is only used in multiway calls. sprang@: Is this correct?

hlundin@ knows more about this test I believe, would you mind taking a look?

It is correct, the target bitrate actually isn't used anywhere yet, but will be used in muc scenarios in the future. I have a hard time seeing that disabling the sending of the occasional unnecessary rtcp overhead would negatively impact performance.

Seems to have recovered in the range 16208-16212 (https://chromium.googlesource.com/external/webrtc/+log/011240333ee22408cdd96d1e4f41dee07af15034..9c3d4c4d881be595dd8e68e2130f23d9f4fab057).

Closing this. We've got bigger fish to fry.