New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 640870 link

Starred by 2 users
Status: Verified
Owner:
█ philipel@chromium.org
Last visit > 30 days ago
Closed: Aug 2016
Cc:
█ emadomara@chromium.org
webrtc-network-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

65.6%-70.3% regression in webrtc_perf_tests at 13893:13894

Project Member Reported by peah@chromium.org, Aug 25 2016 
See the link to graphs below.

Comment 1 by peah@chromium.org, Aug 25 2016 

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

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


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

webrtc-linux-large-tests
webrtc-mac-large-tests

Comment 2 by peah@chromium.org, Aug 25 2016

Owner: philipel@chromium.org
philipel@: Could this regression be related to https://codereview.webrtc.org/2254733005 ?

Comment 3 by brajkumar@chromium.org, Aug 29 2016

Components: Internals>WebRTC

Comment 4 by philipel@chromium.org, Aug 29 2016

Status: Verified (was: Assigned)
This regression is actually my patch restoring the intended behavior. Earlier we always probed at 900 and 1800 kbps, but now we probe at x3 and x6 the start bitrate (in the case of these tests becomes 180 and 360 kbps). Probing now takes the same amount of time as before my patch that caused this "improvement".
►

Sign in to add a comment