New issue
Advanced search Search tips

Issue 791088 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Broken CL identification in WebRTC perf tests?

Project Member Reported by terelius@chromium.org, Dec 1 2017

Issue description

The attached graphs show very clear changes in several metrics. In this case, there is only a single CL on the blamelist and that doesn't change the library at all. However, I have just reverted the immediately preceeding CL because that seemed to cause similar changes on other bots. 

If the results recover, that proves that the mapping between perf results and git hashes is broken.

phoglund@, could you investigate or reassign this to someone appropriate?
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=791088

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=2bf98b8085391a042eec4bf0d4a9332209f489998794ab9b9f590bea5e42dd22


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

webrtc-android-tests-nexus4-lollipop
webrtc-android-tests-nexus5
Owner: ehmaldonado@chromium.org
And the results did recover after your revert! The revert and recover did end up in the right blame range, at least.

Yes, this appears to prove that the WebRTC range is off by one, which is annoying.

Edward, can you look at this when you have time? I'm not sure where WebRTC perf revisions are mapped, maybe recipe_modules/webrtc/steps.py somewhere?
Well, it looks like the results are correctly reported.

If we take a look at the "min_psnr: foreman_cif_500kbps_delay_50_0_plr_3_flexfec" metric for example [1]
* For srte's CL [2], the result was 31.552697 dB. 
* For terelius' CL [3], the result was 28.917786 dB.

And that's what the dashboard is displaying. Also, looking at the bot_update step, the bots are building and testing the right revision.

So, as far as I can see, everything is working just fine...


[1] Click "shard #0 isolated out" in step 29 (webrtc_perf_tests). Then in "test_logs/passed-tests.log", and look for "min_psnr: foreman_cif_500kbps_delay_50_0_plr_3_flexfec"

[2] https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/4618

[3] https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/4619
We already suspected that srte's CL causes massive regressions in multiple metrics, and the metrics recovered when it was reverted. Besides, my CL isn't even compiled into the perf binary so it cannot possibly cause the regression.

The most likely explanation seems to be that there is a mismatch between git hash and/or compiled test binary and/or reported results.
Other bug with >160 alerts for srte's CL
https://bugs.chromium.org/p/chromium/issues/detail?id=791081
Status: WontFix (was: Assigned)
I couldn't find where's the problem.

Sign in to add a comment