[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some thoughts on the ARM build daemons

On Wed, May 09, 2007 at 12:27:04AM +0200, Moritz Muehlenhoff wrote:

> > > > - tofee: up, building packages, sometimes stable-security.
> > > >
> > > > I think it is time to changes things. Our faster build daemons have a
> > > > 233MHz CPU with 256MB of RAM, while there are way faster ARM CPU today.
> > > 
> > > How much faster is the fastest available ARM CPU compared to toffee?
> > 
> > As in, the fastest ARM CPU that exists in the world?  As far as
> > I know, that would be the 1.2 GHz Intel IOP342 (dual core.)
> Are these publicly available and affordable?

I think dev boards for the IOP342 are around $1600 if you buy them
from Intel (will have to double-check that.)  I have an 800MHz
version that I originally got for kernel work, and I think Martin
Michlmayr has an 800MHz version as well.

A 600MHz IOP80219 board (in the form of the Thecus n2100) is about
$270 (USD) on newegg.com with 128M RAM (regular DDR DIMM socket,
upgradable up to 512M) and no disk (takes two SATA disks.)  The
machine that Bill Gatliff made available is of this type.

> If so, let's replace the existing seven buildds with two IOP342;
> it'll reduce the administrative overhead for DSA/buildd admins

Is the number of build machines the current problem, though?

If you never fix machines when they break, having 7 machines is better
than having 2 machines, because if you lose 1 out of 2 machines you lose
half of your build capacity, whereas if you lose 1 out of 7 machines,
it's not a really big deal.

Of course, if the build machines _are_ maintained, then you'd rather
have 2 fast ones than 7 slow ones.  But as soon as one breaks and
doesn't get fixed for half a year, at that point you'd probably wish
you would have had 7 slower ones instead.

> and lower the peak time for arm security builds.

That's true, of course.

For developers, having fast build boxes is nice too, since you don't
have to wait half a day to be able to test a patch.


Reply to: