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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_8bptwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgv6vFpwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_630vAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_9DquwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg__rktgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_5KKrQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_6bvrQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_6L04goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg__D3pwkM


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

webrtc-linux-large-tests
webrtc-win-large-tests

This is not intentional.

What I have found so far is that the time delta between calls to HandleProbeAndEstimateBitrate is always 0 or 1 with my CL, and 0 or 1 except for the first probe with cluster id 1, then the delta is much larger.

So without my CL it looks like this (delta in ms):
273656934, 0, 0, 0, 0, 0, 0, 0, 0, 49, 0, 0, 0
with my CL:
273523983, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

I will continue to look into it.

It looks like the first feedback vector contains information about 7-8 packets, and since we now only require 8 packets (instead of 9) to get the result from both the initial probing attempts we now don't have to wait for an additional 50 ms for the next feedback vector to be delivered, which cause this change.

Also, lots of these tests have been removed now and are not interesting anymore.

Closing.