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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgiouw9ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg8su7qAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgitK1qgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgiu2oogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgitKhswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgitrkhgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgipS9ugkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg8piF_goM


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

webrtc-android-tests-nexus5
webrtc-android-tests-nexus72
webrtc-linux-large-tests
webrtc-mac-large-tests
webrtc-win-large-tests

I don't know how, but you shaved off a whole 15% from the ramp-up time. 120 -> 100 ms. :)

This is likely caused by the rate tracking now being updated for each call, rather than being periodically updated via the process thread (as was the case with the removed bitrate class). 
Also note that the rampup test also has periodic polling, with an interval of 20ms, so the test is triggering a "tick" faster now :)

Think this is OK.