Issue metadata
Sign in to add a comment
|
No data received for browser_tests from chromium-webrtc-rel-linux since 380319 |
||||||||||||||||||||||
Issue descriptionWhen comparing the two builds: https://build.chromium.org/p/chromium.webrtc/builders/Linux%20Tester/builds/14547/steps/browser_tests/logs/stdio https://build.chromium.org/p/chromium.webrtc/builders/Linux%20Tester/builds/14548/steps/browser_tests/logs/stdio It's clear that for audio_bytes_recvonly the metric was changed from bytes_sent to bytes_recv, which seems like a fix. When looking at audio_rates_sendonly, there are three metrics that just disappear. Any of the above observations are hard to explain since the blamelist for the builds at https://build.chromium.org/p/chromium.webrtc/builders/Linux%20Tester/builds/14548/ only shows to changes unrelated to WebRTC
,
Mar 21 2016
So this has now happened again. A lot of perf metrics changed between two seemingly random builds on a single bot. This is similar to bug 585891 which also references older discussions. It annoys me not understanding why this happens. Does anyone remember how this can be?
,
Mar 21 2016
Well, video_resolution_recvonly/goog_frame_width_sent is one disappeared metric. That's good, because it doesn't make sense (it means "the sent frame width of the receive-only peer connection"). The metric appears the first time at 2016-01-20T10:19:26.000Z at commit pos 370356. That doesn't make sense, since that CL does not touch the browser test. Let's dig deeper: 1) The browser test decides to print these metrics depending on what SSRCs that are reported back to us through webrtc-internals: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/media/webrtc_perf_browsertest.cc&q=recvonly&sq=package:chromium&type=cs&l=191. 2) An interesting data point is that https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZylAELEhNTdG9wcGFnZUFsZXJ0UGFyZW50ImZDaHJvbWl1bVdlYlJUQy9jaHJvbWl1bS13ZWJydGMtcmVsLWxpbnV4L2Jyb3dzZXJfdGVzdHMvdmlkZW9fcmVzb2x1dGlvbl9yZWN2b25seS9nb29nX2ZyYW1lX3dpZHRoX3NlbnQMCxINU3RvcHBhZ2VBbGVydBifmxcM has long distances between the data points; sometimes several days. That doesn't make sense since the bot should run way more often than that. If we compare to a healthy metric like https://chromeperf.appspot.com/report?sid=bc376d537ed723ae7823c1cf264ebf47628681e80952a1680c29e0967783aceb, we can see it reports at least 10 times per day. My conclusion is: there is a race condition in webrtc-internals which sometimes show send SSRCs for peer connections that are receive-only. This is what's causing the pollution in the graphs. We could solve this by either making the test less dynamic (filter out the bad ssrc's for one-way tests) or fixing the race.
,
Mar 29 2016
,
Mar 29 2016
I doubt the race in webrtc-internals will be fixed or given priority, so I'll just make a stop-gap solution for now in the test (i.e. never log recv stats for the send-only peer connection). At least, if I manage to make it somewhat clean and not too hackish.
,
Mar 29 2016
Thanks for spending time figuring out this mystery Patrik. I filed bug 598623 to track fixing the root problem.
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/569c778e5750343f2b0b8144a86dec762d61a703 commit 569c778e5750343f2b0b8144a86dec762d61a703 Author: phoglund <phoglund@chromium.org> Date: Tue Mar 29 16:49:14 2016 Filter send-only and recv-only as appropriate in WebRTC perf tests. This should work around the problem where send-only stats appear and disappear because of the race in 598623. BUG= 596398 Review URL: https://codereview.chromium.org/1839653003 Cr-Commit-Position: refs/heads/master@{#383744} [modify] https://crrev.com/569c778e5750343f2b0b8144a86dec762d61a703/chrome/browser/media/webrtc_browsertest_perf.cc [modify] https://crrev.com/569c778e5750343f2b0b8144a86dec762d61a703/chrome/browser/media/webrtc_browsertest_perf.h [modify] https://crrev.com/569c778e5750343f2b0b8144a86dec762d61a703/chrome/browser/media/webrtc_perf_browsertest.cc
,
Mar 30 2016
That should do it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kjellander@chromium.org
, Mar 21 2016