escapewindow: escape window (Default)

Some of you may have noticed that the Maemo Fennec nightly deb repositories now have multiple .install files:

Index of /pub/mozilla.org/mobile/repos/trunk_multi

[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -
[DIR]dists/22-Jun-2010 12:46 -
[   ]trunk_multi_nightly_chinook.install22-Jun-2010 12:43 306
[   ]trunk_multi_nightly_fremantle.install22-Jun-2010 12:44 312
[   ]trunk_multi_nightly_fremantle_qt.install22-Jun-2010 12:46 321


This is due to work done in bug 563767 (enable Maemo5 qt debs) and bug 563081 (deb repo updates with both chinook and fremantle).

Quick terminology table:

DeviceOS VersionMaemo codename
N810Maemo 4Chinook
N900Maemo 5Fremantle

(The QT builds are a variant of the Maemo 5 builds, using the QT toolkit instead of GTK. If you don't know what this is, ignore it :)

These repos should be updated nightly with their corresponding builds. I have seen issues and confusion stemming from having multiple Fennec repos on a single device, so I tend to remove all Mozilla repos from the App Manager, uninstall Fennec+Mozilla Runtime, then click on the appropriate .install file.

Additional instructions available here.

(More QT repos will be available once bug 563770 (enable Maemo 5 QT l10n repacks) starts showing up in tonight's nightly builds.)

[EDIT]: I've renamed the .install files in bug 574104.

escapewindow: escape window (Default)

Maemo N810 talos and unit tests are currently available on the TraceMonkey tree.

In a way, this is a pooling win. Once Lukas enabled the TraceMonkey Maemo builds, I refactored the mobile buildbot configs and made a few tweaks to get TraceMonkey tests running and reporting using the existing device pool. And now we can catch Maemo breakage before it lands in mozilla-central.

There are some known issues:

  1. Fennecmark (Tzoom and Tpan) seems to break the other non-Tp tests. Once I disabled it and removed the jar, the other test suites started running. (bug 506181)

  2. Reftest seems to be broken. When I had a device in front of me, I saw the unresponsive script prompt, which may explain that. No bug yet.

  3. Mochitests are broken on both m-c and TraceMonkey. (bug 503439)

  4. There aren't enough devices to keep up. This is a multi-part issue.

Currently each checkin spawns 10 test suites, the longest of which takes nearly four hours. Afterwards it takes up to a half hour to reboot and reconnect. If we assume a maximum of one checkin in either branch per four and a half hours, 10 functional devices would fully keep up with all checkins.

Of course, it's unrealistic to expect developers to throttle their checkins in m-c and TraceMonkey to one checkin per four and a half hours. Unfortunately, it's also currently unrealistic to expect ten devices to be up and running at any one time. Currently there appear to be 4 functional N810s in production.

The devices weren't really designed to be an enterprise 24/7 test platform, as evidenced by these Maemo bugs. Adding the stress of running constant tests designed for desktops, and my own undiscovered setup bugs, and we lose several (3-6?) devices a night.

Why not buy more? We were considering a pool of 50; if half fell over we'd still be able to handle a large number of builds. The N810 and Diablo might not be the final configuration we end up targeting. Also, until recently, keeping the devices up required hours of daily imaging work.

John Ford recently solved bug 502762, creating a custom image for the N810s, which is awesome. There's still a bunch of testing and ironing out to be done, but this should be a massive time saver. Still, this doesn't allow us to keep up with multiple checkins on multiple branches. Or keep devices up overnight. Just bring them back up faster the next day.

I heard rumblings of wanting Maemo tests on Try. This would add even more load than an additional branch, as Try builds don't allow for build skipping.

We're tracking the N810 stabilization issue in bug 499334. We're working on this while also trying to port tests to two new platforms, and possibly dealing with a new Maemo device. Or, as I call it, 3-5 quarters' worth of work in one quarter's time.

escapewindow: escape window (Default)

(Short version)

Unit tests on Maemo (linux-arm) Fennec are live, viewable on the Mobile tinderbox page. This wouldn't have been possible without the hard work of both Ted and Joel.


(Long version)

Pooling

Previously, I had six Nokia N810s running Talos performance tests (3 running the Tp3 page load test; the other 3 running all the other tests). I triggered all 6 at the same time, build-driven, which resulted in a lot of data for certain builds and no data at all for any builds in between test runs. I knew this wouldn't scale once I added branches and unit tests.

I now have 17 Nokia N810s running Talos + unit tests (14 production, 3 staging). 14 is more than enough to dedicate each N810 to a specific test suite, but:

  1. With test suites of varying time requirements, single-threading the longer-running tests will result in far fewer runs of those tests (while the shorter test devices may be sitting idle), and
  2. There is no depth. If one or two devices fall over, there are no test runs for that test suite until someone intervenes. Having devices fall over is, unfortunately, a not-uncommon event.

Instead, I image each N810 in the exact same way, so they're each capable of running any and all of the test suites. Once pooled, they're available for any buildbot builder to utilize for pending tests. As long as one N810 remains functional, there will be test data (although much slower throughput than with 14).

If these concepts seem familiar, it's because they're the same as what we're doing for Firefox builds and tests.

Splitting

We split the unit tests up out of necessity.

  1. A single run of just the Mochitest suite can take 4-6 hours or more on an N810. Adding other test suites to the same builder would delay test results even further.
  2. The N810 reboots itself when out of memory. Joel had to "chunk" up certain test suites to avoid oom errors/reboots, just to get the tests to run. Splitting the long test suites (namely Mochitest) into multiple parallel tasks was a natural progression.

When pooled, running each test suite individually and splitting Mochitest up into four pieces gives us results much faster than long-running single-threaded tasks.

(The Firefox version of split tests is currently shown on the Firefox-Unittest tree.)

(I have to mention that this capability, running just the unit tests without having to build first, is due to Ted's packaged unit test work in Q1. We are all reaping the benefits now.)

Hacking

I had to write mobile-specific unit test parsers rather than rely on the existing ones.

  1. Since Joel's Maemkit calls run_tests.py multiple times per test suite, the total passed/failed/known numbers at the end of each run are not comprehensive.
  2. In order to have a baseline green, we need to add an additional threshold for tests that are expected to pass on desktop Firefox but failing on Maemo Fennec. This isn't the ideal solution, but it is a relatively fast solution to get the unit tests live and green. We've been discussing different longer-term solutions to this (packaging different tests for different products/platforms? Manifests of known failures per product/platform?)
  3. Since we allow for n number of failed tests per suite, the existence of a "TEST-UNEXPECTED-" string doesn't automatically mean WARNINGS. Instead, I need to m = re.findall("TEST-UNEXPECTED-", string) and compare len(m) against n.
  4. Finally, the numbers on the waterfall (passed/failed/known) are massaged to account for n: I subtract n from the failed number and add it to known. And (hopefully) avoid going negative.

This is all a workaround until we figure out how to solve the different numbers of known failures for the disparate products/platforms.

Stabilizing

There are still some outstanding issues and wanted features above and beyond the above: static IPs for the N810s. Tracking timeouts. Populating a unit test db like Ted's. Otherwise figuring out what causes the reds/crashes and fixing.

I think things are in a state where I can leave it alone for a bit, though. I foresee a whole lot of Windows Mobile and Windows CE in my near-term future.

escapewindow: escape window (Default)

First off, hats off to John Ford, who finished try server mobile builds. Now Firefox developers will have better insight as to whether their patch breaks Maemo and WinCE Fennec builds *before* the patch is committed.


Also, I was struck by how many builds now live on the Mobile tree. Only a handful of months ago (February), joduinn posted this to mark the second column on the tree. Now, the full set (noignore=1) of builds looks like this:

mobile tree
(click?)

(Complete with oranges and broken 1.9.1 builds. We're working on that.)


Finally, this is possibly the end of the Nokia pedalboard, at least as it's currently set up. It's served its purpose well, and has been a definite attention-getter here in building K. But there's an air conditioned shelf reserved in the machine room for the n810s. I suppose we'll see if Windows Mobile devices take over the pedalboard or if I retire it from active mobile device duty.

nokia pedalboard nokia pedalboard nokia pedalboard nokia pedalboard
escapewindow: escape window (Default)
Localized Fennec, filed under "Maemo".
Bits available here*.

--
* Only in tarball format, on trunk, for linux-arm ("Maemo") for now.
escapewindow: escape window (cannibal bears)
nokias

Vorpal bunnies. THE FANGS!!

... The cool news is we're finally reporting Fennec performance data on the Nokia N810's to the staging graph server, which is a big step, but we're still ironing things out. Plus I need to help get the unit tests working/running/automated. And WinCE and [probably] Symbian are around the corner.

But meanwhile, this little pedalboard full o' mobile devices has caught everyone's attention. Here I was trying to just figure out some solution to rackmount these things that didn't involve silly putty, and boom.

I don't have anything on mrz, really.


before


during


after

(previously, previously)

escapewindow: escape window (circuit board)
nokias


A jug of wine, a loaf of bread, a slightly used guitar pedalboard, some velcro, a swiftly growing number of Nokia N810s and N800s running automated Fennec performance and unit tests via buildbot, and thou...

... Can you get started on the wine&bread without me? I'm right in the middle of this script. Be right there.

(previously)

July 2014

S M T W T F S
  12345
6789101112
13141516171819
2021222324 2526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 22nd, 2014 10:20 pm
Powered by Dreamwidth Studios