it's 2.5x faster cpu-wise. However it features an ssd, which is infinitely faster. Seems well worth the 25% price increase. It'll also let us run same HVM amis as bug 944113 needs.

The new m3 medium seems nice. that 4gb ssd should be sufficient for tests

I'll take a look at this

Using m3.medium for linux64 test slaves looks promising. 4G of SSD is quite enough for tests. linux32 isn't suported by m3 though.

(In reply to Rail Aliiev [:rail] from comment #3) > Using m3.medium for linux64 test slaves looks promising. 4G of SSD is quite > enough for tests. linux32 isn't suported by m3 though. 32bit userland should work fine with 64bit kernels..eg our chroot/mock thing will be fine.

We don't use mock on the test slaves. I think we can try to generate an AMI with arch set to 64 bit and 32-bit kernel and userland.

Related (but not wanting to bloat scope): Could we use mock on the test slaves? Having reproducible test environments is a good thing!

I'd rather use something more modern like lxc or docker.

(In reply to Rail Aliiev [:rail] from comment #7) > I'd rather use something more modern like lxc or docker. you have to use a 64bit kernel. 32bit userland will work fine

FTR, we switched to m3.medium for tst-linux64-ec2 slaves on Tue, Jan 28. Spot instances and tst-linux32 slaves are still m1.medium.

(In reply to Rail Aliiev [:rail] from comment #9) > FTR, we switched to m3.medium for tst-linux64-ec2 slaves on Tue, Jan 28. > Spot instances and tst-linux32 slaves are still m1.medium. Shouldn't these bugs become resolved once we switch?

ATM we use m3.medium for all tst-linux64 instances. tst-linux32 still use m1.medium, but since we have less load on those (we don't run b2g tests on them) I would like to defer the switch over in favor of other tasks.

m3.medium didn't stick because we started seeing a lot of timeouts. See bug 969590 and the deps for the details.