Thanks Jonathan for the update.
I would like to point out that at least for the WebRTC tests which do
test the connection between two WebRTC clients we theoretically also
have the option to split the tests into two half's (which we do for
steeplechase tests already anyhow), and then start two
Some more details on how we're approaching this problem from the
infrastructure side:
Releng recently gave us the ability to run select jobs on faster VM's
than the default, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1031083. We have B2G
emulator media mochitests scheduled on cedar usi
I wrote in April:
>The B2G emulator design is causing all sorts of problems. We just fixed
>the #2 orange which was caused by the Audio channel StartPlaying()
>taking up to 20 seconds to run (and we "fixed" it by effectively
>removing some timeouts). However, we just wasted half a week trying to
On Tuesday, April 8, 2014 11:45:15 PM UTC+8, Mike Habicher wrote:
> In my experience running tests locally, a single mochitest run on the
> ARM emulator (hardware: Thinkpad X220, 16GB RAM, SSD) where everything
> was built with 'B2G_DEBUG=0 B2G_NOOPT=0' will run in 2 to 3 minutes. The
> same tes
於 4/15/14, 9:42 PM, Randell Jesup 提到:
I ran crashtest/reftest/marionette/xpcshell/mochitest on emulator-x86-kk,
have filed related bugs and make them block bug 753928. Basically:
1) need to carry "--emulator x86" automatically (bug 996443)
2) to add x86 emulator for xpcshell tests (bug 996473)
>I ran crashtest/reftest/marionette/xpcshell/mochitest on emulator-x86-kk,
>have filed related bugs and make them block bug 753928. Basically:
>
>1) need to carry "--emulator x86" automatically (bug 996443)
>2) to add x86 emulator for xpcshell tests (bug 996473)
>3) PROCESS-CRASH at the end of reft
I ran crashtest/reftest/marionette/xpcshell/mochitest on
emulator-x86-kk, have filed related bugs and make them block bug 753928.
Basically:
1) need to carry "--emulator x86" automatically (bug 996443)
2) to add x86 emulator for xpcshell tests (bug 996473)
3) PROCESS-CRASH at the end of reftes
>>> That is what the emulator is already doing. If we start emulating HW
>>> down to individual CPU cycles, it'll only get slower. :(
>>
>> I think this is wrong in some way. Otherwise I wouldn't see this:
>> 1) running on TBPL (AWS) the internal timings reported show the specific
>>test goin
Hi
>> That is what the emulator is already doing. If we start emulating HW
>> down to individual CPU cycles, it'll only get slower. :(
>
> I think this is wrong in some way. Otherwise I wouldn't see this:
> 1) running on TBPL (AWS) the internal timings reported show the specific
>test going
Randell Jesup writes:
> 1) running on TBPL (AWS) the internal timings reported show the specific
>test going from 30 seconds to 450 seconds with the patch.
> 2) on my local system, the test self-reports ~10 seconds, with or
>without the patch.
> Note: the timer in question is nsITimer::TY
On 4/8/2014 1:05 AM, Thomas Zimmermann wrote:
There are tests that instruct the emulator to trigger certain HW events.
We can't run them on actual phones.
To me, the idea of switching to a x86-based emulator seems to be the
most promising solution. What would be necessary?
Best regards
Thomas
>Hi,
>
>Thanks for bringing up this issue.
>
>>
>> One option (very, very painful, and even slower) would be a proper
>> device simulator which simulates both the CPU and the system hardware
>> (of *some* B2G phone). This would produce the most realistic result
>> with an emulator.
>
>That is wha
On 14-04-07 08:49 PM, Ehsan Akhgari wrote:
On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that
Hi,
Thanks for bringing up this issue.
>
> One option (very, very painful, and even slower) would be a proper
> device simulator which simulates both the CPU and the system hardware
> (of *some* B2G phone). This would produce the most realistic result
> with an emulator.
That is what the emula
Why don’t we just switch to x86 emulator? x86 emulator runs way faster than the
ARM emulator.
Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
On Apr 8, 2014, at 8:49 AM, Ehsan Akhgari wrote:
> On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
>> When you say "debug", you mean the emulator is run
On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that the
emulator is just too slow?
Applying tim
When you say "debug", you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that the
emulator is just too slow?
Applying time dilation might make tests green but we'd be left
>How easy is it to identify CPU-sensitive tests?
Easy for some (most but not all media tests). Almost all
getUserMedia/PeerConnection tests. ICE/STUN/TURN tests.
Not that easy for some. And some may be only indirectly sensitive -
timeouts in delay-the-rendering code, TCP/DNS/SPDY timers, etc,
On 4/7/2014 3:16 PM, Randell Jesup wrote:
> The B2G emulator design is causing all sorts of problems. We just fixed
That sounds very similar to some of the failures seen on the Android 2.3
emulator. Many media-related mochitests intermittently time out on the Android
2.3 emulator when run on aw
How easy is it to identify CPU-sensitive tests?
I think the most practical solution (at least in the near term) is to
find that set of tests, and run only that set on a faster VM, or on real
hardware (like our ix slaves).
Jonathan
On 4/7/2014 3:16 PM, Randell Jesup wrote:
The B2G emulator
The B2G emulator design is causing all sorts of problems. We just fixed
the #2 orange which was caused by the Audio channel StartPlaying()
taking up to 20 seconds to run (and we "fixed" it by effectively
removing some timeouts). However, we just wasted half a week trying to
land AEC & MediaStream
21 matches
Mail list logo
