Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=33539266&repo=mozilla-inbound https://queue.taskcluster.net/v1/task/FzC_5RfySxiWnixpAz7FXg/runs/0/artifacts/public%2Flogs%2Flive_backing.log https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/FzC_5RfySxiWnixpAz7FXg/runs/0/artifacts/public%2Flogs%2Flive_backing.log&only_show_unexpected=1

Nils - 6 failures since I landed. Should we disable this one as well? Should we do something to bump timeouts on android emulator (perhaps a longer-term thing, if we care about emulator - though might help on VMs too)

Hmm this is ICE consent freshness failing on a super simple test case (audio only). I'm worried that if we disable this one we will just continue disabling all PC mochitests on Android emu debug. The only thing which makes this test special is that it's suppose to use PCMA/PMCU, so we might have more network traffic compared to Opus on the network (?), but less CPU overhead. Emulator stats at the end of one of the test runs: TinderboxPrint: CPU idle<br/>11,268.4 (74.8%) TinderboxPrint: CPU user<br/>3,739.6 (24.8%) Daniel: is this test already covered by the Autophone tests?

We're only running the webrtc job on mozilla-central at the moment. I need to fix Bug 1277653 before we can schedule the tests on mozilla-inbound / autoland. I'm addressing review comments on that bug now.

Darn it the Linux failures are false reports. On Linux it never failed on the PcmaPcmu test. Which leaves us with ARM only. Interestingly the second peer connection needs about 1 min until it also disconnect after the first switched to failed. As this should use fixed rate codecs only I really don't see another way then disabling the test on ARM debug for now and then monitor what will fail next.

{ "outbound_rtcp_audio_0": { "ssrc": "2300128555", "bytesReceived": 23840, "jitter": 0.447, "mozRtt": 1, "packetsLost": 0, "packetsReceived": 149 }, "outbound_rtp_audio_0": { "ssrc": "2300128555", "bytesSent": 84360, "packetsSent": 444 }, I think this clearly shows the receiver is hopelessly behind on the RTP packets. I guess there is little we do about it, besides deactivating the test on ARM. Make we wonder if we should do some performance evaluation to figure out where these damn emulator spend all their time. The other idea which came to my mind is that our tests could put up warnings based on the RTCP information I just posted above indicating that the machine appears to be overloaded.

Comment on attachment 8794715 [details] Bug 1293531: disable PcmaPcmu test on Android. https://reviewboard.mozilla.org/r/81052/#review79682 We will still run this on Autophone.

Pushed by drno@ohlmeier.org: https://hg.mozilla.org/integration/autoland/rev/6a20fed1e079 disable PcmaPcmu test on Android. r=dminor