Closed Bug 1293531 Opened 8 years ago Closed 8 years ago

Intermittent dom/media/tests/mochitest/test_peerConnection_basicAudioPcmaPcmuOnly.html | PeerConnectionWrapper (pcLocal): legal ICE state transition from connected to failed

Categories

(Core :: WebRTC, defect, P2)

Product:
Core
Component:
WebRTC
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla52
Tracking Flags:
Tracking Status
firefox50 --- unaffected
firefox51 --- fixed
firefox52 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: drno)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Bug 1293531: disable PcmaPcmu test on Android.
58 bytes, text/x-review-board-request
dminor
: review+
Details
Blocks: 1271585
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)
Rank: 25
Flags: needinfo?(drno)
Priority: -- → P2
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?
Flags: needinfo?(drno) → needinfo?(dminor)
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.
Flags: needinfo?(dminor)
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.
Attachment #8794715 - Flags: review?(dminor) → review+
Pushed by drno@ohlmeier.org:
https://hg.mozilla.org/integration/autoland/rev/6a20fed1e079
disable PcmaPcmu test on Android. r=dminor
https://hg.mozilla.org/mozilla-central/rev/6a20fed1e079
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Assignee: nobody → drno
status-firefox50: --- → unaffected
status-firefox51: --- → affected
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: