freebsd-update/sparc64 and buildworld statistics

Christian Baer christian.baer at
Wed Feb 21 11:50:39 UTC 2007

On Mon, 19 Feb 2007 22:19:58 -0900 Royce Williams wrote:

> It may be that there's no way to break that 1-hour barrier.  Maybe I
> can convince Colin that, until full cross-compiling is available, we
> sparc64 folks would settle for slightly-delayed binary security
> updates (instead of never getting them at all).  It's the very fact
> that we're running on slower hardware that makes freebsd-update so
> attractive.

Actually, I thought cross compiling already worked. The only thing that
was missing is the documentation and some make files???

Currently I'm not having much trouble working with the source updates.
Ok, basicly they suck because compiling takes a pretty long time. But on
my U60 I can start the process when I go to bed and it's done in the
morning. People using a U1E (or anything else that slow) will probably
have to wait a whole day or even more. On the bright side, people using
a U1 unter FreeBSD *probably* won't bei using it as a prodction system,
so they will have a little more time for compiling.

> I'd still like to see what a quad Ultra 80 can do, though. :)  Who has
> access to one of these?

When I win the lottery. :-)

> Chris, did you do any of the other things that the handbook
> 'Rebuilding "world"' section suggests -- noatime /usr/src, async
> /usr/obj, etc?  Also, are you tracking 6.2-STABLE, -RELEASE, or
> something else?  If -STABLE, as of when?  Over time, these data points
> may be relevant.

Not all of the suggestions...

/usr and /usr/obj are seperate file systems on different physical drives
(as I have already written). /usr/obj is mounted async. Since this
system is also an experiment for me the access times of file may be
useful if something goes wrong. And since /usr/src is not a seperate
file system but a small part of /usr, I wanted to keep that on.

I don't think these option will do much for the speed of making a new
world on my machine though. Increasing the throughput of the HDs is
a good idea if the CPU can deliver the information faster than the HDs
can read or write them (as an AMD64 or Core2 Duo could). In our case, I
doubt that the HDs will be the bottle neck, but the limited CPU power.
Both of the CPUs in my U60 show 100% usage almost all of the time. And
since this is a SCSI-system, HD-operation doesn't make the CPU work much
harder either.

The tag for the cvsup ist RELENG_6. This system started out with
6.1-RELEASE and I went from there. I can't tell you how much time has
passed since I did the last buildworld. But it shouldn't make much
difference anyway as the whole system is built from scratch anyway.

uname -a spits this out:
#0: Mon Feb 19 21:33:40 CET 2007
root at  sparc64

>> Well, I'll let you decide where to put the first few benchmarks. :-)
> This'll do until we come up with something better:

At times I am having problems connecting to Maybe we should
get a mirror in Europe. :-)

> Thanks!

No problem!


More information about the freebsd-sparc64 mailing list